BTW můj typický jednoduchý dotaz do tabulky trvá 0.00 sekund (když se použije KEY a tak). vygenerování PHP stránky (jen samotný běh kódu - bez načtení do browseru) trvá typicky např. 0.56 sekund (ve stránce je použitý stejný SQL dotaz a hodnota se vypisuje dříve, než proběhne odeslání nějakého docela komplexního footeru, apod.). No dobře, je tam pár dalších subqueries - ale všechny trvají zanedbatelnou dobu, jsou do tabulek s mizivým množstvím dat, cacheuju je na úrovni PHP apod.

to beru jako finální argument, proč chci bastlit webové aplikace v Céčku místo v PHP: někde někdo něco prostě implementuje hodně špatně a mě ta zbytečná půl sekunda navíc přijde jako obchodní příležitost.

(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?