Prehľad
Čo je to jeden index a čo je kompozitný index? Kedy vytvoriť nový kompozitný index a na čo by som mal v kompozitnom indexe venovať pozornosť? Tento článok je predovšetkým zhrnutím niektorých diskusií na internete.
Jeden. Koncept
Jeden index je situácia, keď je index uvedený v jednom stĺpci, teda príkaz na vytvorenie nového indexu je implementovaný iba v jednom stĺpci.
Používatelia môžu vytvárať indexy na viacerých stĺpcoch, ktoré sa nazývajú kompozitné indexy (kombinované indexy). Kompozitné indexy sa vytvárajú presne rovnakým spôsobom ako jednotlivé indexy. Kompozitné indexy však vyžadujú menšiu režijnú záťaž počas databázových operácií a môžu nahradiť viacero jednotlivých indexov. Keď je počet riadkov v tabuľke oveľa väčší ako počet kľúčov, táto metóda môže výrazne zrýchliť rýchlosť dotazovania tabuľky.
Existujú dva koncepty súčasne, úzke indexy a široké indexy, úzke indexy označujú indexy s 1-2 stĺpcami a zvyčajne označujú jeden index, pokiaľ nie je uvedené inak. Široký index je index s viac ako 2 stĺpcami.
Dôležitým princípom návrhu indexov je používať úzke indexy namiesto širokých, pretože úzke indexy bývajú efektívnejšie ako kombinované indexy. Užšie indexy dávajú optimalizátorovi viac možností, čo často pomáha zlepšiť výkon.
Dva. Použitie
Vytvorte index
Vytvoriť index IDX1 v tabuľke1(stĺp1,stĺp2,stĺpk3)
Informovať
vyber * z tabuľky1, kde stĺp1= A a stĺp2= B a stĺpec3 = C
V tomto čase optimalizátor dotazov neprehľadáva tabuľku, ale priamo berie údaje z indexu, pretože v indexe sú tieto údaje, nazývané overlay query, a rýchlosť dotazu je veľmi rýchla.
Tri. Poznámky:
1. Kedy použiť zložený index
V podmienke kde je pole indexované a ak sa použije viacero polí, použije sa kompozitný index. Vo všeobecnosti nevytvárajte žiadne indexy v poli select (ak chcete dotazovať select stĺpec 1, stĺpce, stĺpce, stĺpce 3 z mytable, vyššie uvedený index nepotrebujete). Indexovanie na základe podmienok je mimoriadne dôležitý princíp. Dávajte pozor, aby ste nepoužívali príliš veľa indexov, inak to výrazne ovplyvní efektivitu aktualizácie tabuliek, pretože pri operačných tabuľkách musíte venovať veľa času vytváraniu indexov.
2. Pre zložené indexy je pri použití query najlepšie postupovať podľa poradia hľadania indexov, ktoré je najefektívnejšie. Napríklad:
IDX1:create index idx1 on table1(col2,col3,col5)
vyberte * z tabuľky1, kde col2=A a col3=B a col5=D
Ak je to "vybrať * z tabuľky1, kde col3=B a col2=A a col5=D"
Alebo "vybrať * z tabuľky1, kde col3=B" nepoužije index, alebo efekt nie je badateľný
3. Nahradí kompozitný index jeden jeden index?
Mnohí si myslia, že pridanie akéhokoľvek poľa do zhlukovaného indexu môže zlepšiť rýchlosť dotazov, ale niektorí sú zmätení: Ak sa zložené zoskupené indexové polia dotazujú samostatne, spomalí sa rýchlosť dotazu? Pri tejto otázke sa pozrime na nasledujúcu rýchlosť dotazu (výsledná množina je 250 000 dát) :( dátumový stĺpec fariqi je na prvom mieste v počiatočnom stĺpci indexu kompozitnej agregácie a používateľské meno neibuyonghu je druhý.
IDX1:create index idx1 on Tgongwen(fariqi,neibuyonghu)
(1) Vyberte gid, fariqi, neibuyonghu, titul od Tgongwena
Kde Fariqi>'2004-5-5'
Rýchlosť dotazu: 2513 ms
(2) vyberte gid, fariqi, neibuyonghu, titul od Tgongwena
kde fariqi>'2004-5-5' a neibuyonghu='kancelária'
Rýchlosť dotazu: 2516 ms
(3) Vyberte gid, fariqi, neibuyonghu, titul od Tgongwena
kde neibuyonghu='kancelária'
Rýchlosť dotazu: 60280 milisekúnd
Z vyššie uvedených experimentov vidíme, že ak sa ako podmienka dotazu použije iba počiatočný stĺpec zhlukovaného indexu, rýchlosť dotazu všetkých stĺpcov s kompozitným zhlukovaným indexom je takmer rovnaká, dokonca o niečo vyššia ako pri použití všetkých zložených indexových stĺpcov (keď je počet súborov výsledkov dotazov rovnaký). Ak sa ako podmienky dotazu použijú iba ne-štartovacie stĺpce zloženého agregovaného indexu, tento index nič neurobí. Samozrejme, rýchlosť dotazovania pre príkazy 1 a 2 je rovnaká, pretože počet položiek v dotaze je rovnaký; ak sú použité všetky stĺpce zloženého indexu a výsledkov dopytu je málo, vytvorí to "indexové prepísanie", aby sa výkon optimalizoval. Tiež majte na pamäti, že bez ohľadu na to, či často používate iné stĺpce v agregátnom indexe, vedúci stĺpec musí byť ten, ktorý sa používa najčastejšie.
[Referencia: Schéma algoritmu optimalizácie dotazov a stránkovania http://blog.csdn.net/chiefsailor/archive/2007/05/28/1628339.aspx]
4. Musím vytvoriť jeden index a kompozitný index v rovnakom stĺpci súčasne?
Experiment: Sysbase 5.0 tabuľka tabuľka1 polia: stĺpec 1, stĺpec 2, stĺpec 3
Testovacie kroky:
(1) Vytvorte index idx1 v stĺpci 1
Vykonajte select * z tabuľky1, kde col1=A používa idx1
Vykonajte select * z tabuľky1, kde kol.1=A a kol.2=B tiež používajú idx1
(2) Vymažte index idx1 a potom vytvorte idx2 na (stĺpec,stĺpc,2) zloženom indexe
Oba dotazy používajú idx2
(3) Ak existujú oba indexy idx1 a idx2
Nie je to tak, že col1='A' používa idx1; kde col1=A a col2=B používa idx2.
Jeho optimalizátor dotazov používa jeden z predtým bežne používaných indexov. Buď použite idx1 alebo idx2.
Dá sa vidieť, že
(1) Pre tabuľku, ak existuje zložený index na (stĺpec 1, stĺpec 2), nie je potrebné vytvárať jeden index na stĺpci 1 súčasne.
(2) Ak to vyžadujú podmienky dotazu, môžete pridať zložený index na (stĺpec 1, stĺpec 2), keď už existuje jeden index na stĺpci 1, čo môže do určitej miery zvýšiť efektivitu.
(3) Nie je veľa výhod pri vytváraní zloženého indexu s viacerými poľami (obsahujúcimi 5 alebo 6 polí) naraz, relatívne povedané, vytvorenie indexu s viacerými úzkymi poľami (obsahujúcim len jedno, alebo maximálne 2 polia) môže dosiahnuť lepšiu efektivitu a flexibilitu.
5. Musím pokryť otázku?
Vo všeobecnosti je najlepšie nepoužívať stratégiu, ktorá zdôrazňuje úplné pokrytie dopytov. Ak sú všetky stĺpce v klauzule Select prepísané neklastrovaným indexom, optimalizátor to rozpozná a poskytne dobrý výkon. To však často vedie k príliš širokému indexu a prílišnej závislosti na pravdepodobnosti, že optimalizátor použije túto politiku. Zvyčajne sa úzke indexy používajú pre väčší počet dotazov, čo poskytuje lepší výkon pri veľkých dotazoch. |
Zverejnené 29. 1. 2015 13:06:03
|
|
|
