当 Azure 推荐包含所有其他列的索引（自然键的一部分）时，我是否应该为此自然键切换到聚集索引？

Question

该表确实有一个身份密钥（当前 CI），但它几乎不用于查询。因为自然键不会不断增加，所以我担心插入性能、碎片或其他我现在无法预见的问题。

桌子并不宽，只有几列。它有大约 800 万行，并且在高峰时段使我们的网站停止运行。（+1000s 并发用户）。数据不容易缓存，因为它非常不稳定并且必须保持最新状态。

自然键的一列有很多读取，但插入和更新也相当活跃。说 8 次读取，1 次更新 vs 1 次插入。

Id (PK)         int
UserId*         int
Key1*           varchar(25)
Key2*           varchar(25)
Key3*           int
LastChanged     datetime2(7)
Value           varchar(25)
Invalid         bit

* this combination is the natural primary key

我大部分时间都需要查询：

• 一个 UserId 的所有行（查询最多）
• UserIds 列表的所有行（很多行）
• Key1 = X 的 UserIds 列表的所有行
• Key2 = X 的 UserIds 列表的所有行
• Key1 = X 和 Key2 = X 的 UserId 列表的所有行

我知道最终的答案总是“描述它”，但我们在这里的时间非常有限，因此我们非常感谢您提前提供任何指导或有经验的意见。

提前致谢，

Answer 1

“因为自然键不会不断增加，所以我\xe2\x80\x99担心插入性能、碎片或其他我现在无法预见的问题。”\n不要听信互联网神话，包括这是关于不断增加的聚类键的问题。\n选择使主键聚集，尤其是代理键，在大多数情况下是一个糟糕的选择。\n聚集索引擅长有序范围扫描，这是代理键永远不会发生的事情。\n每个选择都有优点和缺点，我不会太担心碎片，特别是在引入故意碎片的 RAID 阵列上他们自己的。\n只需监视它，并根据需要重新组织/重建，并为索引提供填充因子，以使其在重新组织之间保持在合理的碎片级别内。

\n\n

事实上，由于聚集键不断增加，这样的活动表可能会遭受“最后一页争用”。此问题的解决方案之一是创建随机访问插入模式，以避免物理页面争用。\n http://download.microsoft.com/download/b/9/e/b9edf2cd-1dbf-4954-b81e -82522880a2dc/sqlserverlatchcontention.pdf \n您所描述的查询模式绝对支持此选择。\n我的建议 - 继续在自然键上创建聚集索引。\n结果可能会让您感到惊讶，并且风险相对较低这么小的桌子。

\n