索引设计:使用日期的聚集索引

Question

每隔一段时间，就需要一张支票。这是一个这样的时刻。

我有用来报告的表格。它们每天被删除/插入一次，或者每天多次从源中“刷新数据”，总是使用连续的日期范围(比如月到日期或滚动的45天)。源数据对它们没有ID或唯一性。

到目前为止，惯例是在日期上使用聚集索引--每个表都有日期，而每个查询都使用日期(99%的时间)。如果表中有一列(S)使其独一无二，那么我已经将这些列添加到集群中，以使其惟一(例如状态和电子邮件)。如果没有，我已经添加了一个ID标识，以使其唯一。

研究似乎建议“使用增量ID”，且偏差很小。然而，使用此约定的性能非常好--除非我在某个地方遗漏了什么。

因此，虽然这是好的，但有时同行检查可能是一件好事:)

• date作为聚集索引中的领先列有什么问题(考虑到上面的情况)？
• 为唯一性添加我自己的ID标识列比为我添加MS更好吗？
• 先添加ID，然后再加日期更好吗？

环境: Azure SQL

Answer 1

date作为聚集索引中的领先列有什么问题(考虑到上面的情况)？

我都想不起来了。通常，在非随机/顺序类型的列上进行聚类是很好的。日期通常很适合这个标准，而不是到处都是的GUID (UNIQUEIDENTIFIERS)。聚集索引是对实际表的逻辑排序(进入B树数据结构)。通过使用非随机或顺序数据类型作为索引键，这允许在为所有相关行寻找B-树的子集时实现最大效率。

为唯一性添加我自己的ID标识列比为我添加MS更好吗？

我不知道为什么要这么做，但我将假设这样做不会对您造成太大的伤害，因为您使用的是一个IDENTITY列，我也假设它很少更改。唯一的缺点是你使你的聚集索引变得更胖了。如果您计划使用任何非聚集索引，结果它们也会稍微重一些，因为所有非聚集索引也都存储聚集索引键。如果计划将频繁更新的列作为聚集索引键的一部分使用，那么这将不利于性能，因为每次键值发生变化时，它都必须更新所有非聚集索引中的所有相关行，这将导致大量额外的阻塞开销。

先添加ID，然后再加日期更好吗？

不，可能不是。如果查询没有在谓词中使用ID字段(JOIN、WHERE、HAVING子句)，那么在索引中引入它将使索引不再适用于这些查询。同样，这是因为数据按照索引中定义的字段的顺序进行逻辑排序。如果B-树首先按ID排序，但您的查询没有按ID进行筛选，那么SQL将无法有效地遍历B-树，直接遍历查询所筛选的行子集。