(co sakra sedíte u compu v neděli? mazejte někam ven)

(pouze jsem chtěl předvést, že i špatný způsob jak řešit problém může vést k velmi zajímavým a plodným výsledkům :-)

ok, končím offtopic vsuvku. a mimochodem, tématem jsou vhodné datové struktury do C aplikací :-) (tak nějak dlouhodobě)

ha, teď to dokonce použvá dva kroky, oba s primary key! :-)

mysql> describe SELECT UNIX_TIMESTAMP(datum) AS unixtime, jmeno, vzkaz, id, hodnoceni, hodnoticich FROM guestbook WHERE id IN (SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0)) ORDER BY id DESC LIMIT 64;
+----+--------------------+-----------+-----------------+-------------------+---------+---------+------+-------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-----------+-----------------+-------------------+---------+---------+------+-------+--------------------------+
| 1 | PRIMARY | guestbook | index | NULL | PRIMARY | 4 | NULL | 11329 | Using where |
| 2 | DEPENDENT SUBQUERY | guestbook | unique_subquery | PRIMARY,hodnoceni | PRIMARY | 4 | func | 1 | Using index; Using where |
+----+--------------------+-----------+-----------------+-------------------+---------+---------+------+-------+--------------------------+
2 rows in set (0.00 sec)

mysql> describe SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0) ORDER BY id DESC LIMIT 64;
+----+-------------+-----------+-------+---------------+-----------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+-------+---------------+-----------+---------+------+-------+-----------------------------+
| 1 | SIMPLE | guestbook | range | hodnoceni | hodnoceni | 5 | NULL | 10333 | Using where; Using filesort |
+----+-------------+-----------+-------+---------------+-----------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)

REDGUY: já top BTW vyřešil high-level SW optimalizací, která BTW funguje i teď, a mj. mi dělá filesort nad menším množstvím dat, než simple dotaz :-)

REDGUY: to bylo až asi ve 4. výsledku, tahle rada :-)

REDGUY: tak samozřejmě... jestli se něco vejde do paměti, nebo ne, to během compile-time nevím. nicméně třeba by pomohlo vidět ten vygenerovaný kód, abych viděl, co od toho čekat, nebo tak?

prostě je víc způsobů, jak přemýšlet o nějaké aplikaci - skriptování vs. kompilovaná aplikace, SQL dotazy vs. nativní storage, objektový vs. neobjektový návrh aplikace, apod. - já hledám nějaký nový level, na který se posunout, protože se zatím plácám uprostřed stejného bastlení, jaké probíhá masově všude kolem mě (a představuje masivní plýtvání zdroji, podle mě)

REDGUY: viz upřesňující zmínka o in-house vývoji :-)

XCHAOS: Ach jo. Njn. Proc proste pouzit to co radi google, kdyz je mozne "zasvecene" tlachat o pouzivani gdb, "ostude" MySQL ktera se pry rozbije kdyz se neco nevejde do pameti, pripadne o hloupych adminech kteri resi problemy prikupovanim pameti, coz? Jak u blbejch 8(

XCHAOS: , že cosi, co se projevuje až od určitého množství záznamů, ti většina adminů bude řešit přiobjednáním paměti - ale prdlajs.

XCHAOS: protože se předem dovím, že jsem napsal dotaz, který třeba nejde jednoduše překompilovat, či tak něco - co myslis tim "jednoduse prekompilovat"? Nechces spis rict "dostatecne zoptimalizovat"? To se sazmorejme nedozvis ani v tvem pripade, protoze ta optimalizace zalezi na databazi a tu behem compile time nemas. Takze, co "tak neco"?

REDGUY: jo, REPAIR table pomohlo, to je fakt :-)

XCHAOS: Sorry, ale fakt nechapu co se vlastne snazis rict. Nejdriv placas neco o tom, ze je ostuda kdyz ma mysql problemy kdyz cela tabulka nevejde do pameti i kdyz se se sloupcema nepracuje (wtf, mimochodem), ted najednou rikas ze velikost sloupcu nehraje roli. Co se vlastne snazis rict? Ze to mas rozbity a netusis proc? Zkousel jsi ten repair table, jak jsem psal? Jakej storage engine ma ta tabulka?

ISTEVE: faktem je, že s velikostí paměti vs. tabulky to nejspíš souvisí, protože chyba se začala projevovat až od určitého množství záznamů - a i výsledky které mi našel na tenhle MySQL error Google naznačují to samé - že se to začalo projevovat až po řádově podobném množstvím záznamů (přes 10 000).

a faktem je, že cosi, co se projevuje až od určitého množství záznamů, ti většina adminů bude řešit přiobjednáním paměti (zvlášť pokud vývoj aplikace neprobíhá in-house, což je u opensource/free software velmi běžné, citatation doufám not needed :-)

REDGUY: prospěje mě - protože se předem dovím, že jsem napsal dotaz, který třeba nejde jednoduše překompilovat, či tak něco :-)

jde o to, že nemám rád, když mi něco přestane fungovat za běhu. to se normálně děje sysadminům, ne programátorům.

XCHAOS: V tom pripade doufam ze neurazi, kdyz to budu povazovat za bullshit vycucanej z prstu -- at uz tebou jakozto back story, nebo autorama reseni "prikoupime pamet", nebo (coz povazuju za nejpravdepodobnejsi) si spojujes dve veci ktery spolu nesouvisej.

XCHAOS: "evidentne"? [citation needed], ale ponevadz odmitas dat solidni dukaz, pak nejen ze to neni evidentni, ale jako bonus to smrdi bullshitem

REDGUY: měl jsem tam blbých 10 000 záznamů a snažím se vydedukovat, co je tam naprogramované blbě. Což není snadné a velikost sloupců v tom velkou roli hrát nebude:

mysql> SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0) ORDER BY id DESC LIMIT 64;ERROR 1030 (HY000): Got error 134 from storage engine

XCHAOS: Podle mě se to otázky pre-kompilace SQL dotazů docela dotýká porad cekame az nam vysvetlis cemu presne ta kompilace prospeje a jak moc.

ISTEVE: no prostě vím o řadě firem, kde by tenhle problém řešili přikoupením RAMěti pro databázový server (reps. přikoupením paměťové kapacity v cloudu) :-) (citation je profesní tajemství, takže nebude)

XCHAOS: u MySQL evidentně hraje roli to, zda se celý obsah tabulky vejde do paměti - Chces rict, ze si myslis ze kdyz mam 10GB tabulku a 1GB pameti, tak s ni MySQL neumi pracovat? Opravdu se snazis rict hole?

REDGUY: ano, skutečně mi to překvapilo. Nicméně potom už neprošel ani ten s nulou, tak to asi byla nějaká zanedbatelná náhoda (šlo prostě o množství výsledků v dotazu, kterých je pro lépe a lépe hodnocené komentáře logicky méně a méně).

Pokud ale dělám jen SELECT id FROM... tak se ta data se kterými dotaz pracuje do paměti bohatě vejdou a dotaz je navíc velice svižný.

Podle mě se to otázky pre-kompilace SQL dotazů docela dotýká - i když jen letmo - protože jak je vidno, tak SQL není tak chytré, jak se snaží předstírat (aspoň MySQL ne)... prostě fakt rád bych zase dělal na kompilovaném projektu, kde některé věci jsou jasné předem a ne až za běhu.