Oracle:betyder kolonnerækkefølgen noget i et indeks?

Hvis a og b begge har 1000 forskellige værdier, og de forespørges altid sammen, så betyder rækkefølgen af kolonner i indekset ikke rigtig noget. Men hvis a har kun 10 forskellige værdier, eller du har forespørgsler, der kun bruger en af kolonnerne, så betyder det noget; i disse scenarier bruges indekset muligvis ikke, hvis kolonnerækkefølgen ikke passer til forespørgslen.
Kolonnen med de mindst distinkte værdier burde være først og kolonnen med de mest distinkte værdier sidst. Dette maksimerer ikke kun nytten af indekset, det øger også de potentielle gevinster ved indekskomprimering.
Datatypen og længden af kolonnen har indflydelse på det afkast, vi kan få fra indekskomprimering, men ikke på den bedste rækkefølge af kolonner i et indeks.
Arranger kolonnerne med den mindst selektive kolonne først og den mest selektive kolonne sidst. I tilfælde af en uafgjort bly med søjlen, som er mere tilbøjelig til at blive brugt alene.

Den ene potentielle undtagelse til 2. og 3. er med DATE-kolonner. Fordi Oracle DATE-kolonner indeholder et tidselement, kan de have 86400 forskellige værdier pr. dag . De fleste forespørgsler i en datakolonne er dog normalt kun interesserede i dagelementet, så du vil måske kun overveje antallet af adskilte dage i dine beregninger. Selvom jeg formoder, at det ikke vil påvirke den relative selektivitet i kun en håndfuld tilfælde.

rediger (som svar på Nick Pierpoints kommentar)

De to hovedårsager til at lede med den mindst selektive kolonne er

Indekskomprimering
Indeks Spring over læsninger

Begge disse arbejder med deres magi ved at vide, at værdien i det aktuelle slot er den samme som værdien i det forrige slot. Derfor kan vi maksimere afkastet fra disse teknikker ved at minimere antallet af gange værdien ændres. I det følgende eksempel, A har fire forskellige værdier og B har seks. Dittoerne repræsenterer en komprimerbar værdi eller en indeksblok, der kan springes over.

Least selective column leads ...

A          B
---------  -
AARDVARK   1
"          2
"          3
"          4
"          5
"          6
DIFFVAL    1
"          2
"          3
"          4
"          5
"          6
OTHERVAL   1
"          2
"          3
"          4
"          5
"          6
WHATEVER   1
"          2
"          3
"          4
"          5
"          6

Mest selektive kolonneafledninger ...

B  A
-  --------
1  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
2  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
3  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
4  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
5  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
6  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER

Selv i dette trivaleksempel, (A, B) har 20 pladser, der kan springes over, sammenlignet med de 18 af (B, A) . En større forskel ville generere større ROI på indekskomprimering eller bedre nytte fra Index Skip-læsninger.

Som det er tilfældet med de fleste tuningheuristik, skal vi benchmarke ved hjælp af faktiske værdier og realistiske volumener. Dette er absolut et scenarie, hvor dataskævhed kan have en dramatisk indvirkning på effektiviteten af forskellige tilgange.

"Jeg tror, at hvis du har et meget selektivt første indeks, så - ud fra et præstationsperspektiv - vil du gøre klogt i at sætte det først."

Hvis vi har en meget selektiv kolonne, bør vi bygge den et eget indeks. De yderligere fordele ved at undgå en FILTER-operation på en håndfuld rækker vil næppe blive opvejet af overheaden ved at opretholde et sammensat indeks.

Indekser med flere kolonner er mest nyttige, når vi har:

to eller flere kolonner med middel selektivitet,
som ofte bruges i den samme forespørgsel.