Pogledajte određenu poruku
Staro 25. 06. 2012.   #12
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

Btw, dve zanimljive stvari.

Konvertovao sam tabele nazad u MyISAM, a ostavio sam ovaj 'grupni' unique key koji mi je ivanhoe predlozio [u stvari, samo sam 'grupni' unique key prebacio u obican 'grupni' INDEX, jer sam skontao da baza sa UNIQUE kljucem pri INSERT-u bespotrebno gubi vreme proveravajuci da li postoji vec takav unos, a to mi nije mnogo bitno, jer imam svoju signalizaciju da ne bi doslo do duplikata].

Dakle, potpuno ista struktura tabele [a ovo da li je UNIQUE KEY ili INDEX nije bitno za SELECT], i sad se desavaju mnogo cudne stvari:
- SELECT koji se izvrsavao po par minuta na InnoDB - sada na MyISAM prosto leti [za manje od sekund zavrsi upit]
- EXPLAIN pokazuje da se koristi ovaj 'grupni' index [navodi ga u polju 'Key' i u polju 'Possible keys'], a u polju 'Extra' kaze: 'Using where; Using index; Using temporary; Using filesort' - fora je sto InnoDB nikako nisam mogao da nateram da ovako radi, uvek je koristio Where umesto indexe... a naglasavam - identicna struktura tabele.

Sve u svemu, zanimljiv case study.
InnoDB je prosto podbacio sa velikom tabelom nad kojom se radi SELECT shirokog ranga.

Inace, sad sam gledao, UPDATE/DELETE se izvrsava za manje od sekunde na MyISAM, iako tabela ima 121 miliona sloga... dakle dzabe sam se tripovao da ga DELETE koči...
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 25. 06. 2012. u 11:43.
Peca je offline   Odgovorite uz citat