Det er svært at sige dette mere kortfattet end SQL Server MVP Brad McGehee:
Som en tommelfingerregel bør hver tabel have et klynget indeks. Generelt, men ikke altid, bør det klyngede indeks være på en kolonne, der stiger monotont - såsom en identitetskolonne, eller en anden kolonne, hvor værdien er stigende - og er unik. I mange tilfælde er den primære nøgle den ideelle kolonne til et klynget indeks.
BOL gentager denne følelse:
Med få undtagelser bør hver tabel have et klynget indeks.
Årsagerne til at gøre dette er mange og er primært baseret på det faktum, at et klynget indeks fysisk bestiller dine data på lager .
-
Hvis dit klyngeindeks er på en enkelt kolonne, stiger monotont, indsættelser sker i rækkefølge på din lagerenhed, og sideopdelinger vil ikke ske.
-
Klyngede indekser er effektive til at finde en specifik række, når den indekserede værdi er unik, såsom det almindelige mønster for valg af en række baseret på den primære nøgle.
-
Et klynget indeks giver ofte mulighed for effektive forespørgsler på kolonner, der ofte søges efter værdiområder (
mellem,> osv.). -
Klynger kan fremskynde forespørgsler, hvor data normalt sorteres efter en eller flere specifikke kolonner.
-
Et klynget indeks kan genopbygges eller omorganiseres efter behov for at kontrollere tabelfragmentering.
-
Disse fordele kan endda anvendes på visninger.
Du ønsker måske ikke at have et klynget indeks på:
-
Kolonner, der har hyppige dataændringer, da SQL Server så fysisk skal omorganisere dataene på lageret.
-
Kolonner, der allerede er dækket af andre indekser.
-
Brede nøgler, da det klyngede indeks også bruges i ikke-klyngede indeksopslag.
-
GUID-kolonner, som er større end identiteter og også effektivt tilfældige værdier (ikke sandsynligt at blive sorteret efter), selvom
newsequentialid()kunne bruges til at afbøde fysisk omarrangering under indsættelser. -
En sjælden grund til at bruge en heap (tabel uden et klynget indeks) er, hvis der altid er adgang til dataene gennem ikke-klyngede indekser, og RID (SQL Server internal row identifier) vides at være mindre end en klynget indeksnøgle.
På grund af disse og andre overvejelser, såsom dine særlige applikationsarbejdsbelastninger, bør du omhyggeligt vælge dine klyngede indekser for at få maksimalt udbytte af dine forespørgsler.
Bemærk også, at når du opretter en primær nøgle på en tabel i SQL Server, vil den som standard oprette et unikt klynget indeks (hvis den ikke allerede har en). Det betyder, at hvis du finder en tabel, der ikke har et klynget indeks, men som har en primær nøgle (som alle tabeller burde), havde en udvikler tidligere taget beslutningen om at oprette den på den måde. Du vil måske have en tvingende grund til at ændre det (som der er mange af, som vi har set). Tilføjelse, ændring eller sletning af det klyngede indeks kræver omskrivning af hele tabellen og eventuelle ikke-klyngede indekser, så dette kan tage lidt tid på et stort bord.