Comprendre comment les colonnes de key primaire sont incluses dans un index non cluster

Le «plan d'exécution réel» d'une table de reference de requête «démo» a suggéré qu'un nouvel index non-cluster non unique est requirejs pour la colonne «b» et devrait inclure la colonne «a».

…

Si la colonne de key primaire 'a' fait déjà partie de l'index non groupé, la colonne 'a' est-elle stockée en tant que colonne d'inclusion ou fait-elle partie de la key non groupée?

Dans votre cas, la colonne a sera présentée sur tous les niveaux de l'index non clusterisé comme partie de la key d'index clusterisée . L'index qui vous est suggéré n'est non-unique , il a donc besoin d'un file unique et la key d'index clusterisée sera utilisée à cette fin.

Si l'index proposé était unique , la colonne a serait stockée au niveau feuille de cet index en tant que partie du localisateur de ligne qui, dans le cas d'une table en cluster, est une key d'index clusterisée.

La colonne a ne sera pas stockée deux fois si vous l'incluez explicitement comme included column de votre index, donc je vous conseille de l'inclure. Cela fera la différence lorsqu'un jour quelqu'un décidera de transformer votre table en grappe (en supprimant l'index clusterisé). Dans ce cas, si vous n'avez pas inclus la colonne a explicitement dans votre index non clusterisé, il sera perdu et ne sera plus contenu dans votre index non clusterisé.

L'inclusion de la colonne a dans a index non clusterisé est inutile car elle fait partie de la key d'index clusterisée. Par conséquent, il fait partie des données dans les pages feuilles de l'index non cluster. Avoir une requête comme celle-ci

 SELECT a FROM tab WHERE b = <value> 

alors la valeur a fera naturellement partie des données de feuille dans l'index non groupé.

Les champs PK font toujours partie de la key de l'index et ne font pas partie des colonnes incluses.

Ce que je pense ici est peut-être qu'il veut chercher dans la colonne B; c'est quelque chose qu'il ne peut faire que si la colonne B est la première key de l'index. Si vous définissez un index avec la colonne B en premier, suivi de la colonne A, peut-être que vous pourrez le faire. Il semble que ce soit heureux tant que les deux keys sont dans l'index, car vous avez un PK composé, bien qu'elles puissent être actuellement dans le mauvais ordre (d'abord A, puis B) empêchant ainsi une search.

Référence sur les champs PK apparaissant automatiquement dans les index: https://www.brentozar.com/archive/2013/07/how-to-find-secret-columns-in-nonclustered-indexes/

Essayez ceci et regardez le plan d'exécution. Vous pouvez voir DB utilise seulement INDEX. Donc, autant que je sache, vous ne devriez pas inclure la colonne A dans votre index (comme vous l'avez dit, la key d'index Clust est déjà incluse).

 CREATE TABLE DEMO (COLA VARCHAR(10) NOT NULL, COLB VARCHAR(10) NOT NULL, COLC VARCHAR(10), COLD VARCHAR(10)); ALTER TABLE DEMO ADD CONSTRAINT DEMO_PK PRIMARY KEY (COLA, COLB); CREATE INDEX DEMO_IX1 ON DEMO (COLB); INSERT INTO DEMO VALUES ('A','B','C','D'); INSERT INTO DEMO VALUES ('A1','B1','C1','D1'); INSERT INTO DEMO VALUES ('A2','B2','C2','D2'); SELECT COLA,COLB FROM DEMO WHERE COLB='B1' 

Les index non groupés incluent implicitement les keys d'index clusterisées automatiquement. Dans la documentation, vous pouvez get beaucoup d'informations à ce sujet, mais surtout cette partie explique exactement ceci:

Architecture d'index non cluster

La couche feuille d'un index non cluster est composée de pages d'index au lieu de pages de données. Les localisateurs de lignes dans les lignes d'index non cluster sont soit un pointeur vers une ligne, soit une key d'index clusterisée pour une ligne.

Si votre table est un tas, le localisateur de ligne pointe directement vers la ligne de données contenant la valeur de key, mais si votre table n'est pas un tas (ce qui est le cas, car vous avez déjà une key en cluster sur cette table) Le localisateur de ligne pointe vers la key d'index clusterisée.

Jetez un coup d'œil aux index clusterisés et non clusterisés décrits également.

Ce thread traite de la même chose: Nécessaire d'inclure des colonnes d'index cluster dans des index non clusterisés?