我有一个相对较大的表（对我来说），有 4000 万行，预计在两周内（在活动期间）将增长到 80 到 1.2 亿行。
Tip
--------------
Id int (clustered index)
UserId int
TipIndex smallint
Value binary(8)
LastChanged datetime2(3)
- 每个用户都有 1 到 400 个提示，这些提示将在此期间随机插入
- UserId + TipIndex 是唯一的
- 我从不直接在身份密钥 (Id) 上查询提示
- 99% 的时间我都在 UserId 上查询
- 我需要所有列
- 我经常查询 1 个 UserId（每个页面视图），有时会查询 10.000 个批次的统计信息
- 在此期间这是一个高流量站点，它应该能够每分钟处理 30.000 次关于 UserId 的查询
- Id 目前是我的聚集索引，因为我读到它导致碎片最少。
所以我在 SQL Azure 上托管，Azure 已经建议添加包含列的索引。我一直对使用 UserId,TipIndex 作为聚集索引犹豫不决，因为提示会随机添加。这意味着我害怕巨大的碎片问题等。
我的问题：
- 包含列的索引没有完全相同的问题吗？
- 包含列的表是否与具有相同碎片问题的“影子表”不同？
- 我是否应该迁移以使用 UserId、TipIndex 作为 ClusteredIndex 而不是 Id？
- 如何防止碎片化？
我知道最终答案总是“取决于”或者我应该衡量它。但由于我是一个单独的开发人员，没有很多资源，我希望有更多经验的人对此有直觉，所以我的第一次尝试更有可能朝着正确的方向前进。
你的问题：
包含列的索引没有完全相同的问题吗？
是的。
包含列的表是否与具有相同碎片问题的“影子表”不同？
是的
我是否应该迁移以使用 UserId、TipIndex 作为 ClusteredIndex 而不是 Id？
我会的，是的。
如何防止碎片化？
有几种不同类型的碎片需要考虑。一种是当您只有部分页面被使用时，因为您有页面拆分。如果你有很多插入，就会发生这种情况。不要压力太大。另一种情况是当您的页面具有不同程度的后续页面时。再说一次，我不会太担心。如果您的数据主要位于缓冲区缓存中，那么它是否跨范围移动并不重要。
所以……不要太担心。但是不要以您实际上不会查询数据的方式获得数据的完整副本。
看来您太在意碎片了，只要您不断更新统计信息，碎片就不应该对性能造成太大影响。您可以在 Brent Ozar 先生分享的视频以及此处的另一个页面上阅读有关此的更多详细信息。让我试着一一回答你的问题：
包含列中的索引或者是关键列，差别不大。关键列将成为 B 树的一部分，而包含列则不是，但是当您执行任何插入/更新/删除操作时，这将具有与这些列需要更新/插入/删除相同的费用。
不太确定影子表是什么意思，如果你在这里指的是基表，那么是的，就碎片而言，你会遇到同样的问题。
根据您的陈述-“我在 UserId 上查询的次数有 99%”，这是主键聚集列的良好候选者。由于您不会非常频繁地使用 Id 列，因此我认为使用 UserId 和 TipIndex 形式的复合主聚集键没有任何问题。就索引的大小而言，它与 Id(int --> 4 byte) 加上一个 tinyint 类型的附加列(1 byte) 一样好。
请理解，集群密钥只不过是逻辑存储的数据顺序，与非集群密钥不同，它没有任何物理存在。
我想说更新统计信息应该比碎片化更优先考虑。您可以使用来自 Ola Hallengren 的世界各地许多 DBA 使用的维护脚本。您可以根据您的要求每周或每两周安排一次。
希望这可以帮助。