autor pise :
Databázové indexy slouží ke zrychlení přístupu k datům a měly by se používat u všech sloupců, podle kterých se vyhledává, třídí nebo podle kterých se spojují tabulky.
mysli se tim i ze by mel byt index na sloupci na nemz typicky dotaz ma selektivitu rekneme 80 % ??? To asi ne, ze pane autore... Vememe li v uvahu ze pristup na rekord pres index je 4x pomalejsi nez pristup primo (napr pri fullscanu) a dal ze indexy zpomaluji update a insert operace, zvysuji naroky na misto apod.. meli bychom rici ze indexy nemuzeme mastit bezhlave jak nas napadne ale na sloupce kde se to vyplati z hlediska dotazu ktere budeme provadet. Flaknu to vod voka rekneme kde selektivita bude do dvaceti procent
ad free SQL urcite doporucim PostgreSQL, nejenom z duvodu ze jednim z vyvojaru je Pavel Zak (napr prepared statements nemylim-li se) ale hlavne proto ze v nem najdete temer vsechno co potrebujete, zvlada poradny objemy dat a ma i nejakej svinsky hezkej gui tool jen si nemuzu vzpomenout jak se jmenuje (nepouzivam ho) napsanej nad WXWindows toolkitem takze jede na stomilionech platforem, myslim pgadmin nebo tak nejak, v mailing listech postgresu je vo nem zminka.
SQL wraperem nad souborovou databazi (cti MySQL) bych se vubec nezabejval. Hracky patri detem.
Ono je škoda, že autor vysvětluje napůl MySQL, místo aby šel jen po indexech. Mimochodem, nesouhlasím s názory na nezabývání se MySQL, protože má svůj účel a je velmi mnoho situací, kde slouží velmi dobře. MySQL nemusí být souborová databáze, taková je pouze, kdy tvoříte tabulky typu "MyISAM", jinak pracuje se segmenty na disku jako jiné transakční databáze. Ale jinak jsem si všiml, že zastánci Postgresu jsou vyjímečně vysazení na MySQL.
Nicméně v indexech se používá pravidlo 20%, tj. pokud index slouží k vyhledání méně, než 20% řádků tabulky, je rozhodně efektivní. U rozsáhlých tabulek je to zase trochu jinak. Osobně se ale domnívám, že prostě potřeba uvážit poměr frekvence použití indexu / zápis. A i to není dokonalé, chce to trochu citu. Zkrátka indexy zpomalují zápis a za určitých situací mohou urychlit čtení, či vyhledání subsetu dat pro úpravy.
Pokud je index používán třeba jen jednou za měsíc, u velkých databází může být výhodné ho těsně před použitím vytvořit a zase po použití dropnout. Atd..
To, že by se indexy měly používat uváženě, je dobrá připomínka a v článku by to mělo být zmíněno. Např. MySQL ale indexy nepoužívá v případě, kdy je potřeba sáhnout na víc než 30% řádek, takže ke zpomalení SELECTu nedojde (ke zpomalení INSERTu však samozřejmě ano). Věřím, že i "chytřejší" databáze budou podobné strategie používat.
Použití indexů i nad sloupci s malým rozptylem má však význam, pokud omezujeme velikost výstupu pomocí LIMIT.
Pouzivaji. Optimalizator databaze obecne by mel vzit do uvahy SQL dotaz, databazove schema (kde jsou jake indexy), aktualni obsah pameti (data v cache) a samozrejme take statistiky o datech (pocet radku, selekcni sila...).
A pote rozhodnout jak postupne zpracovat dotaz, ktere indexy pouzit, jak cist data (treba udelat ten table scan), jak je zamykat...
Optimalizator dotazu je obecne straslive slozita vec. Abyste mohl dopredu rici, ze dotaz pujde po vice nez 30% radku, museli byste mit detailni histogramy. Pro velke tabulky (miliony a vice radku) je to problem, protoze distinct hodnot byva zpravidla desetitisice a vice. Navic histogramy je nutne udrzovat, coz pri vice nez jedne paralelni session pracujici s tabulkou by vyzadovalo neustale soupereni o systemove resources nebo tak jak to dela Oracle, je nutne histogramy a statistiky cas od casu refreshnout.
Dotazy, ktere jsem potreboval optimalizovat jsem vzdycky musel opatrit hinty, nebot databaze neni schopna dotaz vzdy korektne optimalizovat. Delam na Oraclu, ale jinde to bude zrejme to same, nebot princip je ten samy, pouze mnozstvi investovane prace a penez je jine.
nu, někdy je taky možné mít všechno co budu potřebovat přímo v indexu (všechny sloupečky co jsou potřeba pro daný dotaz), takže budu číst třeba 80% dat ale pořád jsem 20% ušetřil. ;)
No to je prave ten figl. Pokud pri pouziti indexu dojde k vyberu vice jak 25% radku, tak se index nepouziva a tabulka se nacita PRIMO (tj. provadi se fullscan) a cteni dat je rychlejsi nez pri cteni pres reference indexu!!!
