Il est difficile d'énoncer cela plus succinctement que le MVP SQL Server Brad McGehee :
En règle générale, chaque table doit avoir un index clusterisé. Généralement, mais pas toujours, l'index clusterisé doit se trouver sur une colonne qui augmente de manière monotone, telle qu'une colonne d'identité ou une autre colonne où la valeur augmente, et qui est unique. Dans de nombreux cas, la clé primaire est la colonne idéale pour un index clusterisé.
BOL fait écho à ce sentiment :
À quelques exceptions près, chaque table doit avoir un index clusterisé.
Les raisons de faire cela sont nombreuses et sont principalement basées sur le fait qu'un index clusterisé ordonne physiquement vos données dans le stockage .
-
Si votre index clusterisé est sur une seule colonne augmente de manière monotone, les insertions se produisent dans l'ordre sur votre périphérique de stockage et les fractionnements de page ne se produiront pas.
-
Les index clusterisés sont efficaces pour trouver une ligne spécifique lorsque la valeur indexée est unique, comme le modèle courant de sélection d'une ligne en fonction de la clé primaire.
-
Un index clusterisé permet souvent des requêtes efficaces sur des colonnes qui sont souvent recherchées pour des plages de valeurs (
between,>, etc.). -
Le clustering peut accélérer les requêtes où les données sont généralement triées par une ou plusieurs colonnes spécifiques.
-
Un index clusterisé peut être reconstruit ou réorganisé à la demande pour contrôler la fragmentation des tables.
-
Ces avantages peuvent même être appliqués aux vues.
Vous ne voudrez peut-être pas avoir un index clusterisé sur :
-
Colonnes dont les données changent fréquemment, car SQL Server doit alors réorganiser physiquement les données dans le stockage.
-
Colonnes déjà couvertes par d'autres index.
-
Clés larges, car l'index cluster est également utilisé dans les recherches d'index non cluster.
-
Les colonnes GUID, qui sont plus grandes que les identités et aussi les valeurs effectivement aléatoires (peu susceptibles d'être triées), bien que
newsequentialid()pourrait être utilisé pour aider à atténuer la réorganisation physique lors des insertions. -
Une raison rare d'utiliser un tas (table sans index clusterisé) est si les données sont toujours accessibles via des index non clusterisés et que le RID (identifiant de ligne interne SQL Server) est connu pour être plus petit qu'une clé d'index clusterisé.
En raison de ces considérations et d'autres, telles que vos charges de travail d'application particulières, vous devez sélectionner soigneusement vos index clusterisés pour tirer le meilleur parti de vos requêtes.
Notez également que lorsque vous créez une clé primaire sur une table dans SQL Server, elle crée par défaut un index clusterisé unique (s'il n'en a pas déjà un). Cela signifie que si vous trouvez une table qui n'a pas d'index clusterisé, mais qui a une clé primaire (comme toutes les tables devraient le faire), un développeur a déjà pris la décision de la créer de cette façon. Vous voudrez peut-être avoir une raison impérieuse de changer cela (dont il y en a beaucoup, comme nous l'avons vu). L'ajout, la modification ou la suppression de l'index clusterisé nécessite la réécriture de l'intégralité de la table et tous les index non clusterisés, cela peut donc prendre un certain temps sur une grande table.
