Structures d'index non-cluster

Les index non cluster possèdent la même structure arborescente binaire que les index cluster, à ces différences près :

• Les lignes de données de la table sous-jacente ne sont pas triées et stockées dans l'ordre des clés non cluster.
• La couche inférieure d'un index non cluster n'est pas constituée de pages de données, mais de pages d'index.

Les index non cluster peuvent être définis dans une table ou une vue dotée d'un index cluster ou d'un segment de mémoire. Chaque ligne d'index de l'index non cluster contient la valeur de clé non cluster et un localisateur de ligne. Ce localisateur pointe vers la ligne de données de l'index cluster ou du segment de mémoire qui contient la valeur de clé.

Dans les lignes des index non cluster, le localisateur est soit un pointeur vers une ligne, soit une clé d'index cluster :

• Si la table est un segment de mémoire (dépourvue d'index cluster), le localisateur de ligne est un pointeur vers la ligne. Le pointeur est construit à partir de l'ID du fichier, du numéro de la page et du numéro de ligne dans la page. Le pointeur complet est appelé une ID de ligne (RID).
• Si la table a un index cluster, ou si l'index est sur une vue indexée, le localisateur de ligne est la clé d'index cluster pour la ligne. Si l'index cluster n'est pas un index unique, SQL Server 2005 rend les clés dupliquées uniques en ajoutant une valeur générée de façon interne, appelée indicateur d'unicité. Cette valeur de quatre octets n'est pas visible pour les utilisateurs. Elle est seulement ajoutée lorsque cela est nécessaire pour rendre la clé cluster unique en vue de son utilisation dans des index non cluster. SQL Server extrait la ligne de données en recherchant l'index cluster à l'aide de la clé d'index cluster stockée dans la ligne feuille de l'index non cluster.

Les index non cluster comprennent une ligne dans sys.partitions où index_id >0 pour chaque partition utilisée par l'index. Par défaut, un index non cluster contient une seule partition. Lorsqu'un index non cluster comprend plusieurs partitions, chaque partition a une structure arborescente binaire qui contient les lignes d'index correspondantes. Par exemple, si un index non cluster a quatre partitions, il y a quatre arborescences binaires, une dans chaque partition.

En fonction des types de données de l'index non cluster, chaque structure d'index non cluster aura une ou plusieurs unités d'allocation dans lesquelles stocker et gérer les données d'une partition spécifique. Chaque index non cluster aura au minimum une unité d'allocation IN_ROW_DATA par partition pour stocker les pages de l'arborescence binaire de l'index. L'index non cluster aura également une unité d'allocation LOB_DATA par partition s'il contient des colonnes d'objets volumineux (LOB). Il aura par ailleurs une unité d'allocation ROW_OVERFLOW_DATA par partition s'il contient des colonnes de longueur variable dont les lignes dépassent 8 060 octets. Pour plus d'informations sur les unités d'allocation, consultez Organisation des tables et des index. Les collections de page de l'arborescence binaire ont pour points d'ancrage des pointeurs root_page dans la vue système sys.system_internals_allocation_units.

Important :
La vue système sys.system_internals_allocation_units est réservée à un usage interne et peut subir des modifications. La compatibilité n'est pas garantie.

L'illustration suivante montre la structure d'un index non cluster avec une seule partition.

Index à colonnes incluses

Dans SQL Server 2005, la fonctionnalité d'index non cluster peut être étendue par l'ajout de colonnes incluses, appelées colonnes non clés, au niveau feuille de l'index. À la différence des colonnes clés qui sont stockées à tous les niveaux de l'index non cluster, les colonnes non clés sont stockées au niveau feuille uniquement. Pour plus d'informations, consultez Index avec colonnes incluses.

Voir aussi

Concepts

Structures des index cluster
Structures des segments
Organisation des tables et des index

Aide et Informations

Assistance sur SQL Server 2005