Autor | Zpráva | ||
---|---|---|---|
lukas87 Profil * |
#1 · Zasláno: 3. 12. 2008, 10:15:52
provedu poprvé sql select a čas jeho provádění je 0,1s další pokusy už trvají 0,001s. Myslel jsem si že se uloží někam co cache a díky tomu se to pak o 2 řády zrychlí, ale... Databázi sem nahrál na mysql server hostingu kde se provádí statisíce možná miliony dotazů za hodinu, první select byl zase 0,1s druhý 0,001 ale asi o 15 hodin později kdy se tento dotaz znovu určitě neprovedl trval zase pouze 0,001s. Že by na takto vytíženém servru byl dotaz v cache 15 hodin to se mi moc nechce věřit. Čím to může být způsobeno? vytvoří servr lepší plán provádění a ten si pak pamatuje nebo opravdu nevím..
|
||
Kajman_ Profil * |
#2 · Zasláno: 3. 12. 2008, 10:52:31
Nepoužití cache pro testování vynutíte v mysql díky
select sql_no_cache ... Obecně může být pravda, že si databázové stroje mohou pamatovat výhodný plán. |
||
lukas87 Profil * |
#3 · Zasláno: 3. 12. 2008, 11:05:40
díky o sql_no_cache jsem nevěděl.
takže to zrychlení není kvůli cache. I když cache zakážu další provádění už je rychlé, takže to asi bude opravdu nějáká uložená optimalizace, ale zajímavý že exekuční plán to ukazuje stejný při prvním pokusu i při dalších... |
||
bohyn Profil |
#4 · Zasláno: 3. 12. 2008, 16:00:49
lukas87
To dlouho si server pamatuje dotaz zalezi na tom kolik ma pameti a jak velka je mnozina provadenych dotazu. Pokud ma server dostatek volne pameti nema duvod zahazovat cache ani po nekolika dnech. Duvod proc je prvni dotaz pomalejsi, bych ale hledal v nespravnem pouziti indexu. MySQL si muze pamatovat jen docasny index a pri dalsich dotazech se uz nezdrzuje jeho vytvarenim. Zkus na dotaz pouzit EXPLAIN sql_dotaz |
||
peta Profil |
#5 · Zasláno: 4. 12. 2008, 07:34:15
lukas87
Take si myslim, ze to jsou spatne indexy. Udelej export struktury tabulky, pridej k tomu dotaz a posli sem. Cache, nevim, jak presne funguje u SQL, ale cekal bych, ze si to pro danou databazi pamatuje nekolik poslednich dotazu neomezenou dobu, pokud neprekrocis nejake tobe vyhrazene misto a pokud se nezmeni data v databazi, vrati vzdy totez. Aspon tak bych resil kesovani ja. |
||
Kajman_ Profil * |
#6 · Zasláno: 4. 12. 2008, 09:17:49
Ještě to může zrychlit cache filesystému, kdy už má potřebnou část souboru s indexem či tabulkou v mezipaměti a nemusí šahat na disk.
|
||
lukas87 Profil * |
#7 · Zasláno: 4. 12. 2008, 09:37:45
dobře zkusím to nějak jednoduše popsat.
Ta databáze je takové simulace e-shopu, konkrétně tento dotaz spojuje tabulku zbozi a menu_cesta, která ukazuje v jakých všech kategoriích se má zboží vypsat. Problém je že ta kategorie musí bý určena jenom slovem (vybere se z url např /pro-psy/krmivo/konzervy/) takže v menu_cesta je pak: id_zbozi m1 (pro-psy) m1 (krmivo) m3 (konzervy) m4 (null) dotaz vypadá takto: SELECT id_zbozi, jmeno, SUBSTRING( popis, 1, 128 ) AS popis, obrazek, CONCAT_WS( '/', `m1` , `m2` , `m3` , `m4` ) AS cesta FROM zbozi JOIN menu_cesta ON zbozi.id = menu_cesta.id_zbozi WHERE m1 = 'pro-psy' AND zobrazeni != '0' ORDER BY prodano DESC LIMIT 0 , 36 řadí se podle různých sloupců, jméno zboží, počet prodaných kusů, cena.. problém asi je že výběr omezuju podle tabulky menu_cesta a to podle čeho potřebuju řadit je v tabulce zboží. |
||
Časová prodleva: 15 let
|
0