spravne oindexovani (II)

[Ales Pour]

Jan Serak wrote:
> 
> Nezapomente, ze trideny vysledne mnoziny zaznamu taky neco vezme.
[...]
> Pokud je trideni dostatecne pomale, tak vyber z tabulky pres index
> nebo sekvencne pres vsecka data nemusi byt rozhodujicim kriteriem.
[...]
> Zkuste to srovnat u dotazu bez order by a uvidite, jak index bude
> znat.

Vzpomel jsem si - tenkrat jsem delal pokusy se bez sortu, a slozeny
index se spravnym poradim to tenkrat urychlil radove. Nynejsi pokusy se
sortem ukazaly jiny problem...

> Honza Pazdziora wrote:
>> No, teda... jako ze si hodne zaswapuje?
> Tak nejak.

[Vysledek je spravny, jenom nevim jak si vylozit, ze EXPLAIN ve sloupci
'rows' uvadel cislo 3689, pritom radek s tim indexem bylo 104395; no
nic...]

Zadrhel je zrejme v maly pameti (16 MB) - jestli si vytahne MySQL (a
nebezi tam jenom ona) do pameti N radek, seradi je a pak mi vrati podle
hodnoty LIMITU, pak skutecne pri vetsim N jede vetsinou po swapu na
disku. Fakt je, ze pokud zacinal slozeny index sloupcem casu, podle
kteryho se vzdycky radilo, tak podle typu razeni ASC/DESC to bylo znacne
rychlejsi ale nekdy taky znacne pomalejsi, ale tady asi odpada razeni
mezivysledku (=naroky na pamet) a slo spis o rychlosti prolezani souboru
od zacatku nebo od konce.No kazdopadne preferuju stabilni casy
zpracovani, ktery zkusim urychlit dalsi pameti.
Mockrat diky za ochotu a mejte se!

	Ales Pour