Lassúság a mefiblogon

« Lassúság »

Van ugye az a gond, hogy az index.php meglehetősen lassan tölt be. Nos, lemértem mindent, és úgy néz ki, hogy a LEFT JOIN okozza a lassúságot. Érdekes, mert ha RIGHT vagy INNER JOIN-ra teszem, akkor villámgyors, de ugye, akkor csak azokat a bejegyzéseket mutatja, amikhez érkezett hozzászólás. Megoldást, valaki?

SELECT `blog`.*, COUNT(`kommentek`.`blogid`) AS `kommentek`, `blogtema`.`tema` AS `temanev`, DATE_FORMAT(`blog`.`datum`,'%Y.%m.%d., %H:%i:%s') AS `datumf` FROM `blog` LEFT JOIN `kommentek` ON `kommentek`.`blogid`=`blog`.`id` INNER JOIN `blogtema` ON `blog`.`tema` =`blogtema`.`temaid` GROUP BY `blog`.`id` ORDER BY `blog`.`id` DESC LIMIT 0,10;

Probléma megoldva: a `blogid` mező nem volt indexelve. Köszönet a segítségért Haszprusnak és Devilllnek.

Kommentek

A bejegyzéshez érkezett kommentek, amiket RSS csatornán is követhetsz.

mindegyikhez hozzászólsz alapból egy pár karaktert, és akkor izé, érted.

/*
mefiblog CSS
(c) 206
mefi – http://mefi.be
*/

Ha mondjuk egy SQL-kérést kaphatnánk…

csinald a kommenteket unionnal. csak vigyazz arra, hogy ugye 2 sort kapsz eredmenyul.

kevesebb bejegyzest kellene irnod :-P

nem a bejegyzesek, hanem a kommentek okozzak a gondot.

http://dev.mysql.com/doc/refman/4.1[…]
Hmm?

> Van ugye az a gond, hogy az index.php meglehetősen lassan tölt be.

Te mit értesz ez alatt egyébként? Sosem tapasztaltam semmilyen lassúságot semerre :)

Tehát számokban kifejezve mennyire lassú nálad az index.php?

van, amikor 1 percig szenved az oldal betoltesevel.

#10

Mondjuk csak a query szalad le ~42 másodperc alatt. :D

#11

Úgy érti, hogy 0.001 másodperc helyett 0.003 alatt tölt be az index.php, és az bizony nem jó. :P

#12

Nem, itt nem 0,x másodperc, lemértem, a rekord 42 másodperc volt, csak az SQL lekérésre. Az meg azért gáz.

#13

(Vannak téma nélküli bejegyzéseid? Ha nincsenek akkor ahhoz nem kell left join.)

#14

Haszprus: van egy-kettő, de ott asszem INNER join van, csak elírtam. :P

#15

Ha én dinamikusan összeállított queryt debuggolok – és a 20+ sorosra növekedett queryjeim miatt mostanság ez elég sokszor előfordult -, akkor azt csinálom hogy először a mysql_query(…) belsejét egy $string-be rakom bele, és a mysql_query($string) -gel hívom meg. A $stringet meg kiechózom és tanulmányozom, nincs-e valami gebasz benne.

Tekintve hogy most pl. elírtad az inner joint, lehet hogy egyéb dolgok is el vannak még írva amikről nem is tudsz :)

Nézd meg hogy pontosan milyen queryt állítasz elő…

#16

Nem, itt írtam el, ahogy felírtam a queryt. A megfelelő helyen nincs elírva, mert működik; csak a left lassul.

#17

„nincs elírva, mert működik; ”

Azért egy 43 mp-ig futó queryre nem mondanám ezt ilyen biztosan, de te tudod :)

#18

Nem azzal van a gond, mert lemértem, a left joinos módszerrel, a kommentekre lassul be.

#19

Indexeled a queryben szereplő mezőket? Mert ha nem akkor lehet hogy megvan a probléma oka :)

#20

Legas küldött egy linket(http://dev.mysql.com/doc/refman/4.1/en/left-join-optimization.html), abban van egy ilyen sor:
MySQL does a full scan on b because the LEFT JOIN forces it to be read before d
A pélád mindenki nézze meg, most nem vágom be ide.
A lényeg, hogy a LEFT JOIN szerintem az egész komment tábládat átnézi, és minden kommenthez hozzácsatolja a blog adatait, ellenben az INNER vagy a RIGHT szerintem ezt csak a szűrések után csinálja meg, tehát jóval kevesebb adatot kell feldolgoznia.

#21

Flatron: ott a pont.

#22

Flatron: ezzel tisztában vagyok, de INNER és RIGHT JOIN esetében csak azokat a bejegyzéseket mutatja, ahol már van komment.

#23

Egy biztos. Én nem használok right joint, és a főoldal legenerálódik mindenestül 0,1 mp alatt*, valamint a teljes 2006-os archívum 0,5 mp alatt (a query-n kívüli mindenféle php-részekkel együtt) úgyhogy nem önmagában a left joinnal van probléma.

* mellesleg kipróbáltam right joinnal, úgy sokszorosa lett, de igazából eddig nem használtam right joint úgyhogy nem biztos hogy szakszerűen írtam át a queryt.

De indexelve vannak-e a mezők, mefi? :)

#24

Melyik mezőre gondolsz, és mit értesz jelen esetben indexelés alatt?

#25

Akkor azt hiszem megvan a probléma :D

#26

Akkor mi lenne, ha a LEFT JOIN-ban beágyazott lekérdezést adnál meg?
SELECT `blog`.*, `kommentek`.`com_num`,
`blogtema`.`tema` AS `temanev`,
DATE_FORMAT(`blog`.`datum`,'%Y.%m.%d., %H:%i:%s') AS `datumf`
FROM `blog`
LEFT JOIN (SELECT `blogid`, COUNT(`kommentek`.`blogid`) AS `com_num` GROUP BY `blogid`) AS `kommentek` ON `kommentek`.`blogid`=`blog`.`id`
INNER JOIN `blogtema` ON `blog`.`tema` =`blogtema`.`temaid`
ORDER BY `blog`.`id` DESC
LIMIT 0,10;
Beágyazott lekérdezés csak akkor megy, ha a MySQL verziója 4.1+.

#27

Na :) Ezen nagyon jót derültem, no offense :)

Indexelés nélkül a mysql szépen végigkeresi az _egész_ adatbázisodat és _minden egyes_ rekordnál lecsekkolja hogy azt keresed-e. (Hát egész konkrétan átlagosan az adatbázisod felét végignyálazza.)

Ha indexelsz egy mezőt, akkor készül egy index tábla, amiben az adott mező értékei sorba lesznek rendezve, így bináris kereséssel lehet keresni benne.

Bináris keresés esetén 10 000 mezős adatbázisnál _maximum_ log2 10 000 = 14 lépésben megvan a keresett mező (maximum!). Lineáris keresés esetén, azaz indextábla nélkül egy mezőt viszont 10 000/2 azaz 5000 lépésben talál meg az sql szerver (átlagosan!). Gondolom érezhető a különbség.

Úgyhogy minden mezőt amire keresést hajtasz végre, kivéve ha a mező változó hosszúságú stringeket tartalmaz, indexelni lehet és kell is.

#28

Haszprus: kicsit pontositsunk: indexelni akkor kell (illetve ajanlott), ha az adott mezore lenyegesen tobbszor keresel (SELECT), mint ahanyszor modositod, torlod vagy ujat szursz be. ha ugyanis tobb a beszuras, modositas, torles, akkor viszont rengeteg ido elmegy az indextablak karbantartasaval, erezheto performance gain nelkul. persze egy blog tipikusan olyan alkalmazas, ahol tobb a SELECT, mint a tobbi, de ez nem feltetlenul van igy mindenhol.

#29

Haszprusz ezt hol olvastad? lehet hogy neked van igazad, de szerintem itt nem a lépések számában van a különbség, hanem hogy az indexelt mezők egy másik fájlban tároládnak el, és az jóval kisebb adatmennyiség, ha azt keresed, hogy melyik sorok blogid-ja 3, akkor azt megnézi az indexben, és azokat a sorokat kiválogatja, index nélkül pedig a táblát nézi végig.

#30

Közben kiderült, indexelve van.

#31

Flatron: „algoritmusok elmélete” bme műinfó 4. félév, „adatbázisok” bme műinfó 5. félév. A lépések száma és miértje elvileg úgy van ahogy mondtam. Elvileg.

Egyébként Haszprus vagyok írásban és kiejtésben egyaránt.

#32

Jeah igazam volt, nem volt indexelve a blogid :)

Új komment

Itt az adott bejegyzésben elhangzottakhoz szólhatsz hozzá. Ha primitív, csúnya, vagy bunkó erkölcsről teszel tanúbizonyságot, tuti, hogy kimoderállak és rosszat mondok rólad. A hozzászólás nem kötelező, amit írsz vállald föl!

Ezeket az adatokat - ha a böngésződ kezeli a kukikat - csak egyszer kell megadnod, később módosíthatod.

Ha van gravatarod - és a gravataros e-mail-címeddel kommentálsz -, akkor az megjelenik. Ha nincs, vagy nem tudod miaz, akkor olvasd el az útmutatót és regisztrálj.

Neved: E-mail címed (nem jelenik meg): Webszájtod (ha van): Kommented: Mennyi három és öt összege?
Ez védelmi célokat szolgál, szimplán írd be a fenti összeadás összegét!

A kommentedet írhatod nagyobb mezőbe vagy akár formázhatod is, de ha nem szalonképes, akkor moderálom!