MySQL - Optimizacija querija

[ivanhoe]

dve ideje koje mozda pomognu (iz mysql manuala):

To help MySQL better optimize queries, use ANALYZE TABLE or run myisamchk --analyze on a table after it has been loaded with data. This updates a value for each index part that indicates the average number of rows that have the same value. (For unique indexes, this is always 1.) MySQL uses this to decide which index to choose when you join two tables based on a non-constant expression. You can check the result from the table analysis by using SHOW INDEX FROM tbl_name and examining the Cardinality value. myisamchk --description --verbose shows index distribution information.

To sort an index and data according to an index, use myisamchk --sort-index --sort-records=1 (assuming that you want to sort on index 1). This is a good way to make queries faster if you have a unique index from which you want to read all rows in order according to the index. The first time you sort a large table this way, it may take a long time.

trebalo bi da ovo prvo traje krace nego optimize, a posto upit koristi index trebalo bi da pomogne takodje. Ovo drugo verovatno nema smisla na tako velikoj tabeli...

[MorenoArdohain]

Iz mog iskustva, na tako velikim tabelama, indexi ne pomazu previse.
Zato ih obicno splitujem po nekom kriterijumu, koji omogucava da ukupno vreme pretrage za sve te tabele uvek bude manje od vremena pretrage za jednu u kojoj su svi recordi.
Naravno, to zahteva vise posla oko inserta i update-a istih (i vise select query-ja), ali mislim da vredi.

[zextra]

Pokusaj da izvrsis isti query, s tim sto ces proveravati "whois_status is not null", pa vidi da li se nesto menja (kako si rekao, za 99% zapisa vrednost je null), bar da znas da li index radi kako treba. Ili eksperimentisi sa preostala dva parametra.. Sto je veci dataset iz kog biras podatke, vece je usporenje, ma koliko da ti je dobar index.

[Dejan Topalovic]

Ako ti je za uslove u WHERE klauzuli cardinality visok (npr. veci od 40% od ukupnog broja redova), onda zaboravi na indexe, jer ce u tom slucaju full table scan uvijek biti optimalniji.

Koju verziju mysql-a imas?

[dinke]

Kako na kom serveru, na serveru gde sam ovo testirao je 5.1.18-beta.

[dinke]

E da, samo da javim da sam ovde napravio "workaround", tako sto sam ovaj query razbio na 2 malo jednostavnija kverija.

Dakle, umesto jednog:

select domain from odm_result_keywords_de 
where whois_status is null and (ovt_ext  > 0 or ovt_ext_local > 0)

Sada imam:

select domain from odm_result_keywords_de 
where ovt_ext > 0 and whois_status is null

i

select domain from odm_result_keywords_de 
where ovt_ext_local > 0 and whois_status is null

U ova dva querija koristi se index na ovt_ext (ovt_ext_local), tako da je zbog niske kardinalnosti (vrlo mali broj slogova ima ovt>0) drasticno manji broj recorda kroz koje upit mora da prodje, sto drasticno ubrzava stvari.