Het is moeilijk om dit beknopter te formuleren dan SQL Server MVP Brad McGehee:
Als vuistregel moet elke tabel een geclusterde index hebben. Over het algemeen, maar niet altijd, moet de geclusterde index zich in een kolom bevinden die monotoon toeneemt, zoals een identiteitskolom of een andere kolom waar de waarde toeneemt, en die uniek is. In veel gevallen is de primaire sleutel de ideale kolom voor een geclusterde index.
BOL herhaalt dit sentiment:
Op enkele uitzonderingen na zou elke tabel een geclusterde index moeten hebben.
De redenen om dit te doen zijn talrijk en zijn voornamelijk gebaseerd op het feit dat een geclusterde index uw gegevens fysiek ordent in de opslag .
-
Als uw geclusterde index op een enkele kolom monotoon toeneemt, worden invoegingen op volgorde op uw opslagapparaat uitgevoerd en worden pagina's niet gesplitst.
-
Geclusterde indexen zijn efficiënt voor het vinden van een specifieke rij wanneer de geïndexeerde waarde uniek is, zoals het algemene patroon van het selecteren van een rij op basis van de primaire sleutel.
-
Een geclusterde index zorgt vaak voor efficiënte zoekopdrachten op kolommen waarin vaak wordt gezocht naar waardenbereiken (
between,>, enz.). -
Clustering kan zoekopdrachten versnellen waarbij gegevens gewoonlijk worden gesorteerd op een specifieke kolom of kolommen.
-
Een geclusterde index kan op verzoek opnieuw worden opgebouwd of gereorganiseerd om tabelfragmentatie te beheersen.
-
Deze voordelen kunnen zelfs worden toegepast op weergaven.
Misschien wilt u geen geclusterde index op:
-
Kolommen met frequente gegevenswijzigingen, aangezien SQL Server de gegevens in de opslag dan fysiek opnieuw moet ordenen.
-
Kolommen die al door andere indexen worden gedekt.
-
Brede toetsen, aangezien de geclusterde index ook wordt gebruikt bij niet-geclusterde indexzoekopdrachten.
-
GUID-kolommen, die groter zijn dan identiteiten en ook in feite willekeurige waarden (waarschijnlijk niet op gesorteerd), hoewel
newsequentialid()kan worden gebruikt om fysieke herordening tijdens invoegingen te verminderen. -
Een zeldzame reden om een heap (tabel zonder geclusterde index) te gebruiken, is als de gegevens altijd toegankelijk zijn via niet-geclusterde indexen en als bekend is dat de RID (SQL Server internal row identifier) kleiner is dan een geclusterde indexsleutel.
Vanwege deze en andere overwegingen, zoals uw specifieke applicatie-workloads, moet u zorgvuldig uw geclusterde indexen selecteren om maximaal voordeel te halen uit uw zoekopdrachten.
Houd er ook rekening mee dat wanneer u een primaire sleutel op een tabel in SQL Server maakt, deze standaard een unieke geclusterde index maakt (als die er nog niet is). Dit betekent dat als u een tabel vindt die geen geclusterde index heeft, maar wel een primaire sleutel heeft (zoals alle tabellen zouden moeten), een ontwikkelaar eerder de beslissing had genomen om deze op die manier te maken. Misschien wilt u een dwingende reden hebben om dat te veranderen (waarvan er veel zijn, zoals we hebben gezien). Voor het toevoegen, wijzigen of verwijderen van de geclusterde index moet de hele tabel worden herschreven en alle niet-geclusterde indexen, dus dit kan enige tijd duren op een grote tafel.