Översikt
Vad är ett enda index och vad är ett sammansatt index? När ska man skapa ett nytt sammansatt index, och vad bör jag vara uppmärksam på i det sammansatta indexet? Den här artikeln är huvudsakligen en sammanfattning av några diskussioner på internet.
Ett. Koncept
Ett enda index är en situation där indexet listas i en kolumn, det vill säga att påståendet att skapa ett nytt index implementeras på endast en kolumn.
Användare kan skapa index på flera kolumner, som kallas sammansatta index (kombinerade index). Sammansatta index skapas på exakt samma sätt som enskilda index. Men sammansatta index kräver mindre overhead under databasoperationer och kan ersätta flera enskilda index. När antalet rader i en tabell är mycket större än antalet nycklar kan denna metod avsevärt öka tabellens frågehastighet.
Det finns två begrepp samtidigt: smala index och breda index, smala index avser index med 1–2 kolumner och syftar generellt på ett enda index om inget annat anges. Ett brett index är ett index med mer än 2 kolumner.
En viktig princip för indexdesign är att använda smala index istället för breda index, eftersom smala index tenderar att vara mer effektiva än kombinerade index. Att ha smalare index ger optimeraren fler valmöjligheter, vilket ofta hjälper till att förbättra prestandan.
Två. Användning
Skapa ett index
skapa index idx1 på tabell1(kol1,kol2,kol3)
Fråga
välj * från tabell1 där kol1= A och kol2= B och kol3 = C
Vid denna tidpunkt skannar inte frågeoptimeraren tabellen, utan tar direkt data från indexet, eftersom det finns denna data i indexet, vilket kallas en overlay-fråga, och frågehastigheten är mycket hög.
Tre. Anteckningar:
1. När man ska använda ett sammansatt index
I where-villkoret indexeras fältet, och om flera fält används används ett sammansatt index. Generellt bör du inte bygga några index i select-fältet (om du vill fråga select col1, col2, col3 från mytable, behöver du inte ovanstående index). Indexering baserat på var villkor är en extremt viktig princip. Var försiktig så att du inte använder för många index, annars påverkar det effektiviteten i tabelluppdateringar mycket eftersom du måste lägga mycket tid på att skapa index när du hanterar tabeller.
2. För sammansatta index är det bäst att följa den ordning som finns i index, vilket är mest effektivt när man använder sökprogram. Till exempel:
IDX1: skapa index idx1 på tabell1 (kol2, kol3, kol5)
välj * från tabell1 där kol2=A och kol3=B och kol5=D
Om det är "välj * från tabell1 där kol3=B och kol2=A och kol5=D"
Eller "välj * från tabell1 där kol3=B" kommer inte att använda indexet, eller effekten är inte märkbar
3. Kommer ett sammansatt index att ersätta ett enda index?
Många tror att det kan förbättra frågehastigheten att lägga till vilket fält som helst i det klustrade indexet, men vissa är förvirrade: Om de sammansatta klustrade indexfälten söks separat, kommer frågehastigheten att sakta ner? Med denna fråga ska vi titta på följande frågehastighet (resultatuppsättningen är 250 000 databitar) :( datumkolumn fariqi rankas först i startkolumnen i det sammansatta aggregationsindexet, och användarnamnet neibuyonghu rankas som nummer två)
IDX1:create index idx1 on Tgongwen(fariqi,neibuyonghu)
(1) Välj Gid, Fariqi, Neibuyonghu, titel från Tgongwen
där fariqi>'2004-5-5'
Frågehastighet: 2513 ms
(2) Välj Gid, Fariqi, Neibuyonghu, titel från Tgongwen
där fariqi>'2004-5-5' och neibuyonghu='kontor'
Frågehastighet: 2516 ms
(3) Välj Gid, Fariqi, Neibuyonghu, titel från Tgongwen
där neibuyonghu = 'kontor'
Frågehastighet: 60280 millisekunder
Från ovanstående experiment kan vi se att om endast startkolumnen i det klustrade indexet används som frågevillkor, är frågehastigheten för alla kolumner med det sammansatta klustrade indexet nästan densamma, till och med något snabbare än att använda alla sammansatta indexkolumner (när antalet frågeresultatuppsättningar är detsamma). Om endast de icke-startande kolumnerna i det sammansatta aggregerade indexet används som frågevillkor, kommer detta index inte att göra något. Naturligtvis är frågehastigheten för satserna 1 och 2 densamma eftersom antalet poster i frågan är detsamma; om alla kolumner i det sammansatta indexet används och frågeresultaten är få, kommer detta att bilda en "indexöverskrivning", så att prestandan kan optimeras. Tänk också på att oavsett om du använder andra kolumner i aggregatindexet ofta eller inte, måste den ledande kolumnen vara den som används mest.
[Ref: Frågeoptimering och pagineringsalgoritm http://blog.csdn.net/chiefsailor/archive/2007/05/28/1628339.aspx]
4. Behöver jag skapa ett enda index och ett sammansatt index på samma kolumn samtidigt?
Experiment: Sysbase 5.0 tabell tabell1 fält: kol1, kol2, kol3
Teststeg:
(1) Skapa indexet idx1 på col1
Exekverar select * från tabell1 där col1=A använder idx1
Exekverar select * från table1 där col1=A och col2=B också använder idx1
(2) Ta bort indexet idx1 och skapa sedan ett idx2 på (col1,col2) sammansatt index
Båda frågorna använder idx2
(3) Om båda indexen idx1 och idx2 existerar
Det är inte där kol1='A' använder idx1; där kol1=A och kol2=B använder idx2.
Dess frågeoptimerare använder ett av de tidigare vanligt använda indexen. Använd antingen idx1 eller idx2.
Det kan ses att
(1) För en tabell, om det finns ett sammansatt index på (kol1, kol2), finns det inget behov av att skapa ett enda index på kol1 samtidigt.
(2) Om frågevillkoren kräver det kan du lägga till det sammansatta indexet på (kol1, kol2) när det redan finns ett enda index på kol1, vilket kan förbättra effektiviteten till viss del.
(3) Det finns inte särskilt många fördelar med att etablera ett sammansatt index med flera fält (innehållande 5 eller 6 fält) samtidigt, relativt sett kan etablering av ett index med flera smala fält (som innehåller endast ett, eller högst 2 fält) uppnå bättre effektivitet och flexibilitet.
5. Behöver jag täcka frågan?
Det är oftast bäst att inte använda en strategi som betonar fullständig sökningshantering. Om alla kolumner i Select-klausulen skrivs över av ett icke-klustrat index kommer optimeraren att känna igen detta och ge god prestanda. Detta leder dock ofta till ett alltför brett index och överdriven beroende av sannolikheten att optimeraren använder policyn. Vanligtvis används smala index för ett större antal frågor, vilket ger bättre prestanda för stora frågor. |
Publicerad på 2015-01-29 13:06:03
|
|
|
