Si la table elle-même est cluster , tous les index secondaires contiennent une copie de la clé de clustering (une clé qui détermine l'ordre physique des lignes dans la table clusterisée).
La raison :les lignes d'une table en cluster sont stockées physiquement dans un arbre B (et non dans un tas de table) et peuvent donc se déplacer lorsque les nœuds B-tree sont divisés ou fusionnés, l'index secondaire ne peut donc pas simplement contenir le "pointeur" de ligne (car il risquerait de "pendre" après le déplacement de la ligne).
Souvent, cela a un effet néfaste sur les performances - l'interrogation via l'index secondaire peut nécessiter une double recherche :
- Tout d'abord, recherchez l'index secondaire et obtenez la clé de clustering.
- Deuxièmement, sur la base de la clé de clustering récupérée ci-dessus, recherchez la table clusterisée elle-même (qui est B-tree).
Cependant, si vous ne voulez que les champs de la clé de clustering, seule la première recherche est nécessaire.
Aka "index clusterisé" sous MS SQL Server.
Habituellement, mais pas nécessairement une CLÉ PRIMAIRE sous MS SQL Server.
Il est regrettable que le clustering soit activé par défaut sous MS SQL Server - les gens laissent souvent la valeur par défaut sans pleinement tenir compte de ses effets. Lorsque le clustering n'est pas approprié, vous devez spécifier explicitement le mot-clé NONCLUSTERED pour le désactiver.
