Jeg er enig med Cade Roux.
Denne artikel burde få dig på rette vej:
- Indekser i SQL Server 2005/2008 – bedste praksis, del 1
- Indekser i SQL Server 2005/2008 – Del 2 – Internals
Én ting skal bemærkes, klyngede indekser bør have en unik nøgle (en identitetskolonne, jeg vil anbefale) som den første kolonne. Grundlæggende hjælper det dine data med at indsætte i slutningen af indekset og ikke forårsage en masse disk-IO og sideopdelinger.
For det andet, hvis du opretter andre indekser på dine data, og de er konstrueret smart, vil de blive genbrugt.
for eksempel. forestil dig, at du søger i en tabel på tre kolonner
stat, amt, zip.
- undertiden søger du kun efter stat.
- undertiden søger du efter stat og amt.
- du søger ofte efter stat, amt, postnummer.
Derefter et indeks med stat, amt, postnummer. vil blive brugt i alle tre af disse søgninger.
Hvis du søger ganske meget på zip alene, vil ovenstående indeks ikke blive brugt (af SQL Server i hvert fald), da zip er den tredje del af det indeks, og forespørgselsoptimeringsværktøjet vil ikke se det indeks som nyttigt.
Du kan derefter oprette et indeks på Zip alene, som ville blive brugt i dette tilfælde.
I øvrigt kan vi drage fordel af det faktum, at med Multi-Column indeksering er den første indekskolonne altid brugbar til søgning, og når du kun søger efter 'state' er den effektiv, men alligevel ikke så effektiv som Single-Column indeks på 'state' '
Jeg gætter på, at det svar, du leder efter, er, at det afhænger af dine hvor-klausuler i dine ofte brugte forespørgsler og også din gruppe-by's.
Artiklen vil hjælpe meget. :-)