OT: Optimalizace selectu v MySQL

[Marek Sembol]

Tak jsem v pameti lovil jeste chvili a vzpomnel jsem si i na
oduvodneni:) Popisu na prikladu (zdaleka to nemusi byt vas pripad.
Cisla strilim hodne z luftu. Dale predpokladam binarni vyhledavani.
Nevim co presne se pouziva, ale podnobny efekt to bude mit IMHO i pri
jinych algoritmech.)....

Mam tabulku s pomerne dlouhymi radky. Pro jednoduchost rekneme, ze
vychazi prave jeden radek na stranku. Dale rekneme, ze hodnot typu
datetime vleze na stranku 1024. A rekneme, ze mam v tabulce 128K
rekordu. Kdyz dam neco hledat, tak nejhorsi pripad je, ze to najdu na
17 porovnani hledane hodnoty.
Pripad A) - dotycny datetime je soucasti PK:
Kdyz dam neco vyhledat podle toho PK. V tom nejhorsim pripade musim
nacist 17 stranek z databaze! (na kazde strance je jen 1 rekord)
Pripad B) - dotycny index mam jako 'normalni' index. Je tedy zvlast v
128 strankach databaze.
Kdyz pres ten index neco hledam, potrebuji v nejhorsim pripadne cteni
7 stranek z databaze! Pak uz jsem na rekordu.
Rozdil pripadu A a B je 10 cteni stranek!

Vim, ze je to vykonstruovane, ale jako demo to snad staci. Neni to z
me hlavy, je to jeste z dob co jsem se pripravoval na MCSE
certifikaci, byla na to v materialech zvlastni kapitola. Jen mi trvalo
si vzpomenout o co tam slo:) Pokud tam byl i priklad, bude obsahovat
presnejsi zduvodneni:)

Marek



On 6/26/07, RV <vicek.radek@cpost.cz> wrote:
> k bodu 2)
>
> obavam se, ze nemate pravdu - pracuji tedy s Sybase, ale vzhledem k
> tomu, ze se tyhle produkty oddelily teprve pred 11 lety neverim, ze by
> doslo k nejakemu vyraznemu odklonu a zmene technologie - PK je index
> pouzitelny jako ostatni indexy - rozdil je jen v tom, ze zaznamy tabulky
> jsou FYZICKY setridene prave podle PK (to je duvod proc nemuze byt vice
> PK - spis ne duvod, ale dusledek) - z toho vyplyva nekolik dusledku -
> treba to, ze pokud dochazi k zapisum do tabulky nahodne zvysuje se rezie
> cele DB nebot rekordy jsou organizovane do zretezenych stranek, ktere
> maji vynechane nejake volne misto (prave proto aby se nemuselo pri
> kazdem zapisu rozpojovat retezce) urcene tzv. fill faktorem - pokud
> misto ve strance dojde vytvori se struktura dalsi stranky a pointry na
> konci a na zacatku dvou stranek se musi upravit na nove vzniklou stranku
> - to ale ma za nasledek velke naroky na cas a diskove operace. Proto se
> voli PK vetsinou tak aby se zapisy pripisovali na konec tabulky - to je
> ostatne i muj pripad - jde o prirozene vznikajici zaznamy na casove ose
> takze neexistuje zapis jinam nez na konec tabulky
>
>

> > 2) [Cerpano z MS SQL, ale neni duvod aby to tady bylo moc jinak]
> > Matne lovim v pameti, ze primarni klic neni zrovna vhodny pro pro
> > vybirani dat. On tam je snad nejaky problem v tom, ze PK neni ukladany
> > zvlast a pro vyber dle primarniho klice se tedy ctou cele rekordy
> >
> > Marek