Als u de maximale ophaalsnelheid wilt en beide kolommen in de join of waar voorwaarden hebt, MAAR soms heeft kolom a een hogere selectiviteit en soms heeft kolom b een hogere selectiviteit, en u wilt profiteren van dat feit vanuit een enkele index.
Ik denk ook dat je verhouding van gegevensomvang / prestatie van de machine behoorlijk hoog moet zijn en tegelijkertijd moet je (gissingen) bereid zijn om elke verbetering een noodzaak te noemen (zelfs al is het maar met een paar procenten).
Toch leert de ervaring dat dingen van veel factoren afhangen; met specifieke RDBMS- en applicatieomgevingen kun je beter je eigen benchmarks draaien.
EDIT:Verdere uitleg over samengestelde indexen.from wikipedia
:
"De volgorde waarin kolommen worden weergegeven in de indexdefinitie is belangrijk. Het is mogelijk om een set rij-ID's op te halen met alleen de eerste geïndexeerde kolom. Het is echter niet mogelijk of efficiënt (op meeste databases) om de set rij-ID's op te halen met alleen de tweede of grotere geïndexeerde kolom.
Stel je bijvoorbeeld een telefoonboek voor dat eerst is geordend op stad, dan op achternaam en vervolgens op voornaam. de stad zijn gegeven, kunt u eenvoudig de lijst met alle telefoonnummers voor die stad extraheren. In dit telefoonboek zou het echter erg vervelend zijn om alle telefoonnummers voor een bepaalde achternaam te vinden. U zou binnen de sectie voor de items met die achternaam."
De uitleg van Wikipedia is misschien overdreven vereenvoudigd, maar het geeft je het basisidee (als analogieën gaan, houd er rekening mee dat telefoonboeken meestal geclusterde indexen hebben en dat dat niet je algemene database-index zou zijn).
Afhankelijk van de grootte van de index versus de grootte van de gegevensstructuur versus het beschikbare geheugen versus de selectiviteit in de eerste kolom van de index, kan het nog steeds veel goedkoper zijn om een verkeerd geordende index te gebruiken dan om tabelscans te gebruiken.
Ah, ik heb net een betere analogie bedacht met een voorbeeld waarnaar u op zoek bent. Stel u een mooi leerboek voor, het zou een inhoudsopgave hebben met hoofdstukken en subhoofdstukken en het aantal pagina's waarop ze zich bevinden (wat een niet-geclusterde index is die verwijzingen bevat naar gegevensrecords - pagina's). Stel u nu voor dat het leerboek op de SQL-92-standaard is, dan zouden de meeste termen in de inhoudsopgave SQL-termen zijn (houd deze veronderstelling vast). U zou ook een andere index aan het einde van het boek hebben die vermeld alle interessante termen in alfabetische volgorde (laten we aannemen met de namen van de belangrijkste hoofdstukken) en paginanummers.
Voor vragen als 'Vertel me alle hoofdstukken waaronder DISTINCT verschijnt' zou je de tweede index gebruiken. (omdat de selectiviteit van het latere veld hoog is)
Voor vragen als 'Vertel me het aantal termen dat onder het eerste hoofdstuk staat' zou je de inhoudsopgave gebruiken
Dus voor vragen als 'Is SELECT beschreven onder DML hoofdstuk?' u zou een van de indexen kunnen gebruiken. (omdat de selectiviteit van beide velden hoog is) Als de TOC van DML zelf echter 3 pagina's lang is en het SELECT-item in de index slechts vijftien regels heeft, zou u waarschijnlijk naar de tweede gaan, en dat is een voorbeeld van wanneer u profiteert van beide indexen.
Als u dat te vergezocht vindt, denk dan eens aan een database van de gescande bibliotheek van het congres. :)
Zoals ik al eerder zei, alle planning is prima, maar voer uiteindelijk je eigen benchmarks uit.