zanimljiv problem, mozda kroz information_schema ? nisam siguran da moze ali mi nista bolje ne pada na pamet

kako?

nasao sam ove linkove:

http://www.oreillynet.com/data...ing_redundant_indexes_usi.html

http://www.mysqlperformanceblo...indexes-and-redundant-indexes/

za sada cu u java-i da pisem kod koji ce da detektuje i ukloni indexe mada ostaje otvoreno da se to nekako resi u SQL-u

sigurno ne mozes da uradis alter table from select .... to ne radi, moras da uradis alter po alter tu nemas izbora ... ali listu altera mozes da napravis iz information_schema.statistics .. uz malo gimnastike, mislim da ima upit koji je pisao Roland pre 5-6 godina ali ne znam napamet njegov blog (umrla mi makina pa sam malo osakacen) .. ovi linkovi sto si stavio lice na Petra no on uglavnom uvek prica o tome kako ne valja da imas duple indexe, da su naisali neki tool koji cisti duple indexe bio bi deo maatkit-a (ili kako se vec danas to zove, mada ko zna mozda ima u maatkitu neki tool za to proveri pre nego krenes da pises svoj, perkona je u maatkit uglavila mnogo mega korisnih stvari!!)

u svakom slucaju guglni nesto tipa "roland bouman mysql redundant index" i trebalo bi da iskopas ako ne direktno Rolandov blog onda bar neki artikl njegov na tudjem blogu

sta god da napravis baci ovde resenje siguran sam da ce mnogima koristiti :)

sad vidim ovaj tvoj prvi link sto si nasao to je Rolandov tekst!!!

bogi, da te nema, trebalo bi te izmisliti!

http://rpbouman.blogspot.com/2...ndant-indexes-using-mysql.html

upit je kobaja grande ali daje rezultat koji deluje, uglavnom, ok. koliko sam video na mom primeru, ubacio je u redundantne indexe i one za koje je Piter rekao da bas i ne bi bili redundantni (UQ/covering index vs FK index):
- FK index ne bih dropovao nikako
- UQ/covering indexe takodje ne bih dropovao

sve ostalo je odlicno!

nisam ti preterano pomogao, to je taj na koji sam mislio ali ti si ga vec bio nasao na orajliju samo ja nisam prepoznao artikl ... Roland je mega iskusan lik tako da savetujem da prelistas njegov blog ima bas mnogo korisnih informacija ... ranije je imao foru da prvo baci post nama na listu da iskomentarisemo, odavno to vise ne radi :( posto je zapalio, jeli, od nas... lik pise mega kvalitetno (ne zaboravi da je on u mysql-u radio na razvoju certifikacionih i trening kurseva)

Percona duplicate key checker (ex. maatkit key checker) sasvim lepo radi...izbaci listu duplih indexa, alter za svaki pojedinacni pa onda odlucis koji da dropnes.

Hibernate u nekom automatskom modu (ili kako vec to funkcionise) pored vec postojeceg PK za npr. polje ID napravi i unique key pa cesto se tu nadje jos i "obican" index za isto polje ID. To su duplirani indexi i zadnja dva se mogu bez mnogo razmisljanja skloniti. Sada ako postoji index (A,B,C) i jos pojedinacni indexi (A), (B) i (C) onda zavisi koji se upite najvise vrte.

Ako se samo (najvise) vrte: ...where A= and B = and C=... i ...where A=.... onda su i (A) i (B) i (C) nepotrebni (zanemarujuci koja polja izvlaci iz select, FK...)

Ako se dosta vrt i nesto kao ...where A=... OR B=... pa jos ima dosta i SELECT C.... onda je sve potrebno :) a (skoro) uvek moze i da se prekomponuje upit, aplikacija itd