使用带有覆盖列的唯一非聚集索引而不是主键的含义

Question

我们有一个大表[MyTable]目前既有Primary Key，和一个Unique Non Clustered Index在同一列（[KeyColumn]）。UNC 索引还有额外的覆盖栏。

在同一列上同时拥有 PK 和唯一 NC 索引似乎是多余的，所以我考虑删除主键，而是使用唯一非聚集索引来实现引用完整性。

请注意，该表完全由另一列聚集在一起。

即所以我们有：

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

和

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

据我所知，不可能向主键添加覆盖列，所以我打算这样做：

• 删除依赖的外键约束 MyTable.KeyColumn
• MyTable.KeyColumn完全删除主键
• 将外键重新添加到表中（即 RI 将通过 强制执行MyTable.KeyColumn）

我能想到这样做的唯一含义是我们不会在 ERD 图表上得到可视化的关键符号，并且（叶）索引密度会因为包含的列而减少。

我已阅读/sf/ask/34112011/并且对这样做的完整性和性能方面感到满意。

我的问题是：这种方法有缺陷吗？

编辑 我想要完成的工作：性能优化和春季大扫除。通过删除 PK 或索引，我的索引将需要更少的页面 = 更快的写入，加上维护/操作的好处，即少一个索引来保持碎片整理等。

为了提供一些背景知识，我以前从未有过没有 PK 的表被引用。但是，将带有覆盖列的 NC 索引添加到表中这一事实意味着我需要调整我的想法。

Answer 1

性能优化。通过删除 PK 或索引，索引所需的页面将减少 = 写入速度更快，此外还有维护/操作优势，即减少一个用于保持碎片整理的索引等。

您需要能够证明所提议的内容实际上会有所帮助（成本与收益）。考虑这一改变的原因是什么？该表实际上是否存在性能问题，或者只是“看起来错误”？

以下是一些其他问题，可帮助您做出适合您环境的最佳决策：

• 维护时段可以节省多少时间？在备份窗口中？

• 这将节省多少存储空间（数据文件、日志文件、备份等）？

• INSERT该表的性能现在真的是瓶颈吗？会改善多少？删除索引是解决该问题的最佳策略吗？

• 这是否会导致数据库工具和框架（特别是 ORM）出现问题，这些工具和框架期望每个表都有一个主键而不仅仅是一个唯一索引？事务复制需要已发布表上的主键。

• 自记录数据库模式重要吗？

• 尽管其用途有限，但主键索引的狭窄性是否仍然允许优化器为某些查询生成更有效的计划？（使用sys.dm_db_index_usage_stats来找出答案。）

就我个人而言，根据您告诉我们的情况，我会先不管它，直到可以证明（a）额外的索引是一个问题，并且（b）删除它是解决方案。