Det är svårt att säga detta mer kortfattat än SQL Server MVP Brad McGehee:
Som en tumregel bör varje tabell ha ett klustrat index. I allmänhet, men inte alltid, bör det klustrade indexet finnas på en kolumn som ökar monotont – som en identitetskolumn, eller någon annan kolumn där värdet ökar – och är unik. I många fall är primärnyckeln den idealiska kolumnen för ett klustrat index.
BOL ekar denna känsla:
Med några få undantag bör varje tabell ha ett klustrat index.
Anledningarna till att göra detta är många och är främst baserade på det faktum att ett klustrat index fysiskt ordnar din data i lagring .
-
Om ditt klustrade index finns på en enda kolumn ökar monotont, infogning sker i ordning på din lagringsenhet och siddelningar kommer inte att ske.
-
Klustrade index är effektiva för att hitta en specifik rad när det indexerade värdet är unikt, till exempel det vanliga mönstret att välja en rad baserat på primärnyckeln.
-
Ett klustrat index tillåter ofta effektiva frågor på kolumner som ofta söks efter värdeintervall (
mellan,> , etc.). -
Klustring kan påskynda frågor där data vanligtvis sorteras efter en specifik kolumn eller kolumner.
-
Ett klustrat index kan byggas om eller omorganiseras på begäran för att kontrollera tabellfragmentering.
-
Dessa fördelar kan till och med tillämpas på visningar.
Du kanske inte vill ha ett klustrat index på:
-
Kolumner som har frekventa dataändringar, eftersom SQL Server sedan fysiskt måste ordna om data i lagringen.
-
Kolumner som redan täcks av andra index.
-
Breda nycklar, eftersom det klustrade indexet också används i icke-klustrade indexuppslagningar.
-
GUID-kolumner, som är större än identiteter och även i praktiken slumpmässiga värden (som sannolikt inte sorteras efter), även om
newsequentialid()kan användas för att minska fysisk omordning under insättningar. -
En sällsynt anledning till att använda en heap (tabell utan ett klustrat index) är om data alltid nås via icke-klustrade index och RID (SQL Server intern radidentifierare) är känd för att vara mindre än en klustrad indexnyckel.
På grund av dessa och andra överväganden, såsom dina speciella applikationsarbetsbelastningar, bör du noggrant välja dina klustrade index för att få maximal nytta av dina frågor.
Observera också att när du skapar en primärnyckel i en tabell i SQL Server, kommer den som standard att skapa ett unikt klustrade index (om den inte redan har en). Det betyder att om du hittar en tabell som inte har ett klustrat index, men som har en primärnyckel (som alla tabeller borde), hade en utvecklare tidigare tagit beslutet att skapa den på det sättet. Du kanske vill ha en övertygande anledning att ändra det (som det finns många av, som vi har sett). Att lägga till, ändra eller ta bort det klustrade indexet kräver omskrivning av hela tabellen och eventuella icke-klustrade index, så detta kan ta lite tid på ett stort bord.