Når du vil have den maksimale genfindingshastighed og har begge kolonner i sammenføjningen eller hvor betingelserne, MEN nogle gange har kolonne a højere selektivitet og nogle gange har kolonne b højere selektivitet, og du vil udnytte dette faktum fra et enkelt indeks.
Jeg tror også, at dit forhold mellem datastørrelse og ydelse af maskinen burde være ret højt, og samtidig skal du (gætte) være villig til at kalde enhver forbedring for en nødvendighed (selvom kun med nogle få procenter).
Alligevel lærer erfaringen, at tingene afhænger af mange faktorer; med specifikke RDBMS og applikationsmiljøer kan du bedre køre dine egne benchmarks.
EDIT:Yderligere forklaring på sammensatte indekser.fra wikipedia
:
"Rækkefølgen, hvori kolonner er opført i indeksdefinitionen, er vigtig. Det er muligt at hente et sæt rækkeidentifikatorer ved kun at bruge den første indekserede kolonne. Det er dog ikke muligt eller effektivt (på de fleste databaser) for at hente sættet af række-id'er ved kun at bruge den anden eller højere indekserede kolonne.
Forestil dig f.eks. en telefonbog, der er organiseret efter by først, derefter efter efternavn og derefter efter fornavn. Hvis du får byen, kan du nemt udtrække listen over alle telefonnumre for den by. Men i denne telefonbog ville det være meget kedeligt at finde alle telefonnumrene til et givet efternavn. Du ville være nødt til at kigge i hver bys sektion for poster med det efternavn."
Wikipedias forklaringer er måske alt for forenklede, men det giver dig den grundlæggende idé (som analogier skal du huske på, at telefonbøger normalt har klyngede indekser, og det ville ikke være dit generelle databaseindeks).
Afhængigt af størrelsen af indekset vs størrelsen af datastrukturen vs tilgængelig hukommelse vs selektivitet i den første kolonne af indekset, kan det stadig være meget billigere at bruge forkert ordnet indeks end at bruge tabelscanninger.
Ah, tænkte lige på en bedre analogi med et eksempel, du leder efter. Forestil dig en god lærebog, den ville have indholdsfortegnelse med kapitler og underkapitel og antallet af sider, hvor de er på (som er et ikke-klynget indeks, som indeholder pegepunkter til dataposter - sider). Forestil dig nu, at lærebogen er på SQL-92-standarden, så ville de fleste af termerne i TOC være SQL-udtryk (holder denne antagelse). Du ville også have et andet indeks i slutningen af bogen, som ville liste alle de interessante udtryk i alfabetisk rækkefølge (lad os antage med hovedkapitlernavne) og sidetal.
For spørgsmål som "Fortæl mig alle kapitlerne, hvorunder DISTINCT vises" ville du bruge det andet indeks. (fordi selektiviteten i det senere felt er høj)
For spørgsmål som "Fortæl mig antallet af termer, der vises under første kapitel", ville du bruge indholdsfortegnelsen
Så for spørgsmål som 'Er SELECT beskrevet under DML-kapitlet?' du kan bruge et af indekserne.(fordi selektiviteten af begge felter er høj) Men hvis TOC i selve DML er 3 sider lang, og SELECT-indgangen i indekset kun har femten linjer, ville du sandsynligvis gå til den anden, og det er et eksempel på, hvornår du nyder godt af begge indekser.
Hvis du nu synes, det er for langt ude, så tag en database over kongressens scannede bibliotek i betragtning. :)
Som jeg sagde før, er al planlægning i orden, men til sidst skal du køre dine egne benchmarks.