Grupni ili pojedinacni index?

Zelim da indeksiram neka polja u tabeli i tako da ubrzam pretragu tabele, tj. SELECT upite.

Pretragu tabele vrsim u zavisnosti od vrenosti nekoliko kolona.

Da bi ubrzao pretragu zelim da indeksiram sve koline koje mi zahvata WHERE u upitu.

E tu sam u dilemi, da li da za svaku kolonu formiram poseban indeks,
ili da napravim jedan indeks koji obuhvata vise kolona?

Kada se koriste grupni indeksi i po kom principu rade?

Potpis

Aukcije, www.Odbrojavanje.com
Aukcija može biti osvojena jeftino - za 30 sekundi a 6 dinara!

mysql u jednom upitu ne ume da koristi vise indexa .. posebno ne u "obicnom" upitu .. a u nekom "kompleksnom" ume da koristi najvise 3 tako da ti je bolje da pravis kompozitni key nego zasebne ...

takodje obrati paznju na redosled polja u kompozitnom kljucu posto nije svejedno

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Pozdrav,
evo da te ne otvaram nvu temu a da pitam nesto sto me duze vreme interesuje...

Vise putao sam procitao da je bitan redosled kolona u index - u, zanima me kriterijum na osnovu kog se odredjuje taj redosled. Da li je to red kojim join - ujem tabelu sa drugim ili nesto drugo... ?
Ovde je konkretno bilo reci o mysql - u, da li isti kriterijum vazi i za MS SQL.... ?

Potpis

Linkedin: http://www.linkedin.com/in/sladjannikolic
Twitter: https://twitter.com/_SladjanNikolic

Samo jedno pitanje, kako to mysql ne ume u jednom upitu da koristi vise indeksa?? Ovo mi je stvarno cudno!

Potpis

Aukcije, www.Odbrojavanje.com
Aukcija može biti osvojena jeftino - za 30 sekundi a 6 dinara!

stevs, zavisi od optimizera ... na primer ako radis

SELECT a, count(a) from t1 where b=10 and c > 100 group by a;

kompozitni index treba da bude (b,c,a) posto prvo filtriras po b i c, pritom je b eq a c range i onda na kraju grupises po c

za ms sql - nemam ideju, oni su svoj optimizer iskopirali od sybase-a .. a ne znam ni tamo kako je to radilo ali mislim da je prilicno slicno

zgas, lepo - ne ume :) dakle ako imas upit

select a from t1 where a>10 and b<100;

i imas indexe i_a(a) i i_b(b) on ce da uzme u obzir oba indexa a upotrebice onaj za koji mu table status (cardinality) kaze da ce da odbaci veci deo tabele (dakle koristice onaj index za koji on misli da ce mu dati manji rezultat) i onda ce nad rezultatom da odradi scan za onu drugu vrednost. - nece koristiti "oba indexa".

Ako imas losu statistiku moze da se desi da mysql omasi i upotrebi sporiji index... u tom slucaju mozes da koristis hinting da optimizeru kazes koji mu je index bolji, ili pak da forsiras upotrebu nekog indexa.
http://dev.mysql.com/doc/refman/5.1/en/index-hints.html



malo duzu pricu na tu temu na pricu sa indexima imate ovde: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

da jos jedan bitan detalj ... nekad ce mysql odluciti da odradi index merge ... http://dev.mysql.com/doc/refma.../index-merge-optimization.html

nije stvar na koju se treba osloniti posto "spajanje indexa" traje neko vreme .. posebno na vecim tabelama, tako da je uvek bolje imati spreman kompozitni kljuc ...

naravno, index merge radi samo od 5.0.nesto pa na vamo ..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Hvala na odgovoriu, skapirao sam ovo... Gledajuci na ovaj nacin index je "vezan" za upit, pa me zanima koliko utice na perfomanse ako imam vise kompozitnih index - a.... ?

Potpis

Linkedin: http://www.linkedin.com/in/sladjannikolic
Twitter: https://twitter.com/_SladjanNikolic

indexi uticu na perfomanse na svim sistemima isto ... index nad nekom tabelom usporava upis u tu tabelu (delete/insert/update) .. sto vise indexa - sporiji upis ...
isti taj index ako moze da se upotrebi za select - ubrzace ga drasticno..

postojanje indexa samog za sebe samo zazima prostor na disku ... isto tako, za select - index nece da smeta, mozda ce koju milisekundu duze optimized da bira koji ce index da koristi ako ih ima vise nego ako ih ima manje ali sve u svemu visak indexa ovde ne pravi problem ...

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Mnogo ti hvala, razjasnio si mi neke stvari...

Potpis

Linkedin: http://www.linkedin.com/in/sladjannikolic
Twitter: https://twitter.com/_SladjanNikolic

nema na cemu ... obrati paznju uvek .. EXPLAIN ce ti objasniti kuda / kako optimizer radi tj kako ce izvrsiti upit ... optimizer mnogo zavisi od tacnih podataka o statistici tabela i ako su ti podaci netacni vrlo je moguce da ce da izabere pogresan put za izvrsavanje upita ... ovo resavas na nekoliko nacina

analyze table - ovo ce da pokupi statistiku tabele - obrati paznju da ume da potraje na vecoj tabeli

optimize table - ovo ce pored toga sto ce da optimizuje tabelu odraditi i analyze

index hint - kazes optimizeru da hoces "bas taj index" da koristis (budi siguran da znas sta radis)


MyISAM prilicno dobro cuva statistiku tako da su podaci prilicno / ako ne i uvek skroz ok ... InnoDB je tu mnogo losiji, on "pretpostavlja" statistiku i posle nekog vremena mu te vrednosti pobegnu od stvarnih.... neki drugi storage engine-i (na primer ndbcluster) uopste nemaju statistiku (tako da je korisno forsovati indexe hintovima za iole kompleksnije upite) ...

obavezno pogledaj ova dva linka

http://dev.mysql.com/doc/refman/5.0/en/using-explain.html
http://20bits.com/articles/10-...-mysql-queries-that-dont-suck/

zgas, stevs jeste malo preoteo tok thread-a ali sve ovo je relevantno i za tvoje originalno pitanje ...

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

pera me spijunira :D :D :D

http://www.mysqlperformanceblo...column-indexes-vs-index-merge/

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Znaci:
Imam SELECT razlicite upite na istoj tabeli.
Ovi upiti treba da budu sto brzi.
Svaki od njih koristi razlicite kolone u WHERE da bi selektovali rezultat.

Resenje je:
Da se za svaki upit naprave kompozitni (grupni indeksi) kolona koje se koriste u WHERE izrazima.

Da li sam dobro napisao?
I drugo pitanje posto sam laik u indeksiranju, da li indeksi ubrzavaju GROUP BY, ORDER BY i sl. ako se ovim naredbama pozivaju indeks kolone

Potpis

Aukcije, www.Odbrojavanje.com
Aukcija može biti osvojena jeftino - za 30 sekundi a 6 dinara!

da ali ne :)

racunaj da ako na primer imas index (a,b,c,d) index koji bi bio (a,b,c) je visak posto ga (a,b,c,d) pokriva ... dakle (a,b,c,d) pokricva (a), (a,b), (a,b,c) i (a,b,c,d) a u nekim slucajevima pokriva i (a,c), (a,c,d) na primer ali ne uvek



[/quote]

da ali ne uvek ... tj. prilicno je razlicita upotreba indexa za group by i za order by, za group by ce se koristiti index ako postoji za order by ce se koristiti u zavisnosti od statistike posto je nekada brze rezultat sortirati bez koristenja indexa ..

kao sto vidis ne postoji "finalni odgovor", posebno sto optimizer dosta "pogadja" i vrlo cesto mu se desi da promasi kao i zato sto mysql sam po sebi ume da koristi za jedan upit samo jedan kljuc (i kada koristi vise njih opet koristi jedan samo ga izgenerise od tih drugih ... to je merge key, intersection key etc.. )

sve u svemu - ako hoces malo dublje da udjes u materiju procitaj sadrzaj sa tri linka iz prethodna dva posta .. imas tamo na perinom blogu super primere kako se ponasa optimizer na jednostavnom primeru

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Da li mislis na ovaj blog "http://www.mysqlperformanceblo...column-indexes-vs-index-merge/".

Bogdane, mislim da si rekao da jednostavan SELECT moze da koristi samo jedanu kolonu kao indeks ili vise kolona ako su grupisane kao jedan indeks.

Iz ovoga bloga sam zakljucio da mysql u jednostavnom SELECTU ipak koristi vise odvojenih indeksa i da ih nije potrebno grupisati te indekse.

... da li sam dobro shvatio?

Potpis

Aukcije, www.Odbrojavanje.com
Aukcija može biti osvojena jeftino - za 30 sekundi a 6 dinara!

yup, pera napisao 2 minuta posto sam ja postovao ovde, zato sam rekao da me "pera spijunira" :) ... covek je vrlo dobar poznavalac mysql-a, moj bivsi kolega koji je odlucio da mu je bolje da otvori svoju firmu te je onda povukao jos par ljudi ... svi do jednog zaposleni tamo su nekada bili moje kolege



da i ne ... dakle ako pogledas sesti post od pocetka, napisao sam da ce mysql ponekad da odradi index merge i ostavio ti link na mysql dokumentaciju koja govori kada i kako index merge radi. kao sto se da videti iz dokumentacije, index merge se generise u vrlo retkim slucajevima i ne valja k***u .. a to se da sve videti i iz primera sa perinog bloga ..

da pojasnim .. select a from t where x >10 and y < 20; je super jednostavan upit - gde ce mysql koristiti iskljucivo jedan index, dakle koristice index merge samo u slucaju da su oba uslova eq. dakle kada dizajniras bazu i upite, slobodno mozes da izignorises index merge i da napravis kompozitne kljuceve koji odgovaraju tvojim potreba

nadam se da je sad jasnije

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

btw, jedan dodatni info .. http://www.mysqlperformanceblog.com/ je ubedljivo najjace mesto gde mozes da procitas nesto o optimizaciji mysql-a - petar zajcev je jedan od najboljih support inzenjera koji je ikad radio u mysql-u, vadim, morgan (btw morgan je odusevljen beogradom i klopom koju je jeo ovde :D ) ... sve su to mnoooooooogo iskusni likovi sa mnooooooogo znanja, i deo tog znanja stavljaju na taj blog .. dakle to je mnoooooogo dobro mesto za skupljanje informacija.. po meni - vezano za performanse "obicnog mysql-a sa innodb-om kao osnovnim storage engineom" - ubedljivo najbolji izvor informacija!

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/