[ staleks @ 03.07.2012. 15:26 ] @
Pozdrav,

hteo bih da postavim pitanje u vezi tumacenja EXPLAIN naredbe u MySQL-u.

Imam jedan upit koji merenjem performansi pokazuje da traje preko 10s na nekih c.c.a. 500k zapisa.

Situacija je sledeca:

Korisnik entitet je podeljen na 2 tabele: Profile i User. (ne pitajte zasto i kako - applikacija je nasledjena i nema se mesta za mnogo menjanja)
Profile i User su vezani u odnosu Jedan - na - Jedan. Mada je moguce da u jednoj (ili cak obe) ima zapisa koji nemaju svog parnjaka u ovoj drugoj.
Takodje nepitajte zasto jer su podaci nasledjeni.

Upit koji je "problematican" je sledeci

Code:

SELECT p.`sifra`
FROM `profile` p, `user` u
WHERE p.`id` = u.`profile_id` AND p.`online` = FALSE AND p.`stvarno_online` = TRUE AND u.`datum_poslednjeg_logovanja` < "2012-07-03 15:55";


Pri cemu se ovaj query izvrsava svakih 1h, oko 13 - 15 sec svaki put.

p.sifra je dodan kao index u profile tabeli.

Ukoliko izbacim zadnji WHERE uslov (datum_poslednjeg_logovanja), i izvrsim EXPLAIN naredbu, dobijem sledeci result set

Code:

id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra
1|SIMPLE|u|index|FK_USER_PROFILE|FK_USER_PROFILE|8|(NULL)|473905|Using index
1|SIMPLE|p|eq_ref|PRIMARY|PRIMARY|8|db.u.profile_id|1|Using where


Medjutim kad ukljucim i zadnji WHERE onda se situacija menja:

Code:

id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra
1|SIMPLE|u|ALL|FK_USER_PROFILE|(NULL)|(NULL)|(NULL)|473905|Using where
1|SIMPLE|p|eq_ref|PRIMARY|PRIMARY|8|db.u.profile_id|1|Using where


Koliko sam video po nekim forumima, tutorijalima ALL kao type TREBA UVEK IZBEGAVATI.

Pokusao sam cak i sa dodavanjam index na datum_poslednjeg_logovanja koloni ali nije dalo znacajnije rezultate u performansama.


Da li bi neko bio ljubazan da mi objasni kako tumaciti EXPLAIN i da li je moguce i kako poboljsati performanse na ovom primeru.

Hvala


[Ovu poruku je menjao staleks dana 04.07.2012. u 09:30 GMT+1]
[ bogdan.kecman @ 03.07.2012. 16:02 ] @
1. zatvaraj kod u [ code ] tagove da bi se zadrzalo formatiranje ovako je extra nepregledno
2. drugi explain ti pokazuje full table scan
3. prvi explain koristi index
4. gde su create table?
5. citao http://dev.mysql.com/doc/refman/5.5/en/mysql-indexes.html ?
6. citao http://dev.mysql.com/doc/refma...xecution-plan-information.html ?
[ bjevta @ 10.07.2012. 19:06 ] @
prvo, definisi join kako treba, FROM profile p JOIN user u ON ...

drugo, dodaj u tabelu user composite index: profile_id + datum_poslednjeg_logovanja

trece, explain zavisi i od broja slogova. execution plan uzima u obzir kojesta tako da moras da probas nad realnom bazom.

e, da, kad testiras performanse SELECT-a, obavezno pisi SELECT SQL_NO_CACHE ... U protivnom, prvi upit bude spor, ostali brzi.