Oracle:is de kolomvolgorde van belang in een index?

1. Als a en b beide hebben 1000 verschillende waarden en ze worden altijd samen opgevraagd, dan doet de volgorde van de kolommen in de index er niet echt toe. Maar als a heeft slechts 10 verschillende waarden of u hebt vragen die slechts een van de kolommen gebruiken, dan maakt het wel uit; in deze scenario's mag de index niet worden gebruikt als de kolomvolgorde niet past bij de zoekopdracht.
2. De kolom met de minst duidelijke waarden moet als eerste staan ​​en de kolom met de meest duidelijke waarden als laatste. Dit maximaliseert niet alleen het nut van de index, het verhoogt ook de potentiële voordelen van indexcompressie.
3. Het gegevenstype en de lengte van de kolom hebben invloed op het rendement dat we kunnen halen uit indexcompressie, maar niet op de beste volgorde van kolommen in een index.
4. Rangschik de kolommen met de minst selectieve kolom eerst en de meest selectieve kolom als laatste. In het geval van een gelijkspel leidt u met de kolom die waarschijnlijker alleen wordt gebruikt.

De enige mogelijke uitzondering op 2. en 3. is met DATE-kolommen. Omdat Oracle DATE-kolommen een tijdselement bevatten, hebben ze mogelijk 86400 verschillende waarden per dag . De meeste query's op een gegevenskolom zijn echter meestal alleen geïnteresseerd in het dag-element, dus misschien wilt u in uw berekeningen alleen rekening houden met het aantal verschillende dagen. Hoewel ik vermoed dat het de relatieve selectiviteit in slechts een handvol gevallen niet zal beïnvloeden.

bewerken (in reactie op de opmerking van Nick Pierpoint)

De twee belangrijkste redenen om te leiden met de minst selectieve kolom zijn

1. Indexcompressie
2. Index Lezen overslaan

Beide werken hun magie door te weten dat de waarde in het huidige slot hetzelfde is als de waarde in het vorige slot. Bijgevolg kunnen we het rendement van deze technieken maximaliseren door het aantal keren dat de waarde verandert te minimaliseren. In het volgende voorbeeld, A heeft vier verschillende waarden en B heeft er zes. De ditto's vertegenwoordigen een samendrukbare waarde of een indexblok dat kan worden overgeslagen.

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

Meest selectieve kolomleads ...

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

Zelfs in dit trivale voorbeeld, (A, B) heeft 20 over te slaan slots vergeleken met de 18 van (B, A) . Een grotere ongelijkheid zou een grotere ROI genereren op indexcompressie of een beter nut van Index Skip-lezingen.

Zoals het geval is met de meeste afstemmingsheuristieken, moeten we benchmarken met behulp van werkelijke waarden en realistische volumes. Dit is zeker een scenario waarin het scheeftrekken van gegevens een dramatische impact kan hebben op de effectiviteit van verschillende benaderingen.

"Ik denk dat als je een zeer selectieve eerste index hebt, je er vanuit een prestatieperspectief goed aan doet om deze op de eerste plaats te zetten."

Als we een zeer selectieve kolom hebben, moeten we er een eigen index voor bouwen. De extra voordelen van het vermijden van een FILTER-bewerking op een handvol rijen zullen waarschijnlijk niet opwegen tegen de overhead van het handhaven van een samengestelde index.

Indexen met meerdere kolommen zijn het nuttigst als we het volgende hebben:

• twee of meer kolommen van middelmatige selectiviteit,
• die vaak in dezelfde zoekopdracht worden gebruikt.