Implications de l'utilisation d'un index non cluster unique avec des colonnes de couverture au lieu d'une clé primaire

Nous avons une grande table [MyTable]qui a actuellement à la fois un Primary Key, et un Unique Non Clustered Indexsur la même colonne ( [KeyColumn]). L'indice U NC comporte également des colonnes de couverture supplémentaires.

Avoir à la fois PK et Unique NC Index sur les mêmes colonnes semble redondant, donc j'envisageais de supprimer la clé primaire et d'utiliser à la place l'index Unique Non Clustered à des fins d'intégrité référentielle.

Notez que la table est entièrement groupée par une autre colonne.

donc nous avons:

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

ET

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

Pour autant que je sache, il n'est pas possible d'ajouter des colonnes de couverture à une clé primaire, j'ai donc l'intention de faire:

• Supprimez les contraintes de clé étrangère qui dépendent MyTable.KeyColumn
• Déposez la clé primaire MyTable.KeyColumnentièrement
• Ajoutez à nouveau les clés étrangères à la table (c'est-à-dire que RI sera appliqué via MyTable.KeyColumn)

La seule implication à laquelle je peux penser est que nous n'obtiendrons pas le symbole de clé visuelle sur nos diagrammes ERD, et que la densité d'index (feuille) sera inférieure en raison des colonnes incluses.

J'ai lu /programming/487314/primary-key-or-unique-index et je suis satisfait des aspects d'intégrité et de performances de cette opération.

Ma question est: cette approche est-elle défectueuse?

Modifier ce que j'essaie d'accomplir : optimisation des performances et nettoyage de printemps . En supprimant le PK ou un index, il y aura moins de pages nécessaires pour mes index = des écritures plus rapides, ainsi que des avantages de maintenance / d'exploitation, c'est-à-dire un index de moins à conserver défragmenté, etc.

Pour mettre un peu de fond à cela, je n'ai jamais eu auparavant de table référencée, sans PK. Cependant, le fait qu'un index NC avec des colonnes de couverture ait été ajouté au tableau signifie que je dois adapter ma réflexion.

Optimisation des performances. En supprimant le PK ou un index, il y aura moins de pages nécessaires pour mes index = des écritures plus rapides, ainsi que des avantages de maintenance / opérationnels, c'est-à-dire un index de moins à conserver défragmenté, etc.

Vous devez être en mesure de prouver que ce qui est proposé vous aidera réellement (coût vs avantage). Pour quelle raison ce changement est-il envisagé? Existe-t-il réellement des problèmes de performances avec ce tableau, ou est-ce qu'il "semblait mal"?

Voici quelques autres questions qui vous aideront à prendre la meilleure décision pour votre environnement:

• Combien de temps serait économisé dans la fenêtre de maintenance? Dans la fenêtre de sauvegarde?

• Combien d'espace de stockage cela économiserait-il (fichiers de données, fichiers journaux, sauvegardes, etc.)?

• Les INSERTperformances sur cette table sont -elles vraiment un goulot d'étranglement en ce moment? Dans quelle mesure cela s'améliorerait-il? La suppression d'un index est-elle la meilleure stratégie pour résoudre ce problème?

• Cela causera-t-il des problèmes avec les outils et les infrastructures de base de données (ORM en particulier) qui s'attendent à ce que chaque table ait une clé primaire et pas seulement un index unique? La réplication transactionnelle nécessite une clé primaire sur les tables publiées.

• Un schéma de base de données auto-documenté est-il important?

• Malgré son utilisation limitée, l'étroitesse de l'index de clé primaire permet-elle toujours à l'optimiseur de produire des plans plus efficaces pour certaines requêtes? (Utilisez sys.dm_db_index_usage_statspour le savoir.)

Personnellement, d'après ce que vous nous avez dit, je le laisserais tranquille jusqu'à ce qu'il soit prouvé que (a) l'index supplémentaire est un problème, et (b) le supprimer est la solution.

Le seul type de requête sur cette table qui fonctionnera moins bien (et seulement un peu moins bien) sera celui qui demandera une plage de valeurs KeyColumn - car ces requêtes pour le moment seraient mieux servies par une recherche d'index sur votre PK.

Il convient de garder à l'esprit que le coût de la vérification de l'intégrité référentielle pour les tableaux qui référencent ce tableau sera plus élevé (encore une fois légèrement plus élevé).

Tant que vous vous occupez de l'aspect nullable, alors vous devriez être très bien avec l'index unique.

Si c'était ma base de données, je choisirais probablement le seul index unique, toutes choses étant égales par ailleurs.

Pour autant que je sache, il n'est pas possible d'ajouter des colonnes de couverture à une clé primaire

Si vous avez un index cluster sur KeyColumn, puisqu’il s’agit d’un index cluster, toutes les autres colonnes sont implicitement «couvertes». Vous ne gagnez donc rien en ajoutant un autre index sur KeyColumn. En fait, vous ralentirez vos insertions et utiliserez plus d'espace.

En effet, un index cluster n'est pas un index en tant que tel, mais simplement une instruction pour stocker les lignes de la table dans l'ordre de l'index. Et une fois que vous avez trouvé une ligne par clé primaire, vous avez là toutes les autres colonnes.