索引设计：使用 DATE 的聚集索引

Question

每隔一段时间，人们就需要进行一次检查。这就是这样一个时刻。

我有用于报告的表格。它们每天删除/插入一次或每天多次，以始终使用连续的日期范围（例如本月至今或滚动 45 天）从源“刷新数据”。源数据没有 ID 或唯一性。

到目前为止，约定是在日期上使用聚集索引 - 每个表都有一个日期，每个查询都使用一个日期（99% 的时间）。如果表中有一个或多个使其唯一的列，我已将这些列添加到集群中以使其唯一（例如，状态和电子邮件）。如果没有，我添加了一个 ID IDENTITY 以使其唯一。

研究似乎建议“使用递增的 ID”，几乎没有偏差。然而，使用这个约定的性能非常出色——除非我在某个地方遗漏了一些东西。

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

• 将日期作为聚集索引中的前导列是否存在任何问题（考虑上述情况）？
• 添加我自己的 ID 身份列以获得唯一性是否比 MS SQL 为我做的更好？
• 先加ID，再加日期会不会更好？

环境：Azure SQL

Answer 1

将日期作为聚集索引中的前导列是否存在任何问题（考虑上述情况）？

我脑子里没有一个能想到的。通常最好聚集在非随机/顺序类型的列上。日期通常很符合这个标准，而不是UNIQUEIDENTIFIERS到处都是 GUID ( )。聚集索引是实际表的逻辑排序（B 树数据结构）。通过使用非随机或顺序数据类型作为索引键，可以在查找所有相关行的 B 树子集时实现最高效率。

添加我自己的 ID 身份列以获得唯一性是否比 MS SQL 为我做的更好？

我知道没有理由这样做，但我假设你这样做不会造成太大伤害，因为你使用的列IDENTITY我也假设很少改变。唯一的缺点是你让你的聚集索引变得更胖了。如果您计划使用任何非聚集索引，它们也会因此变得稍微重一些，因为所有非聚集索引也存储聚集索引键。如果您计划使用经常更新的列作为聚集索引键的一部分，那么这对性能来说不太好，因为每次键值更改时，都必须更新所有非聚集索引中的所有相关行此外，还会因阻塞而导致大量额外开销。

先加ID，再加日期会不会更好？

不，可能不会。如果您的查询未使用ID谓词（JOIN, WHERE,HAVING子句）中的字段，则在索引中使用该字段会使该索引不再适用于这些查询。同样，这是因为数据是按照索引中定义的字段的顺序进行逻辑排序的。如果 B 树首先按 排序ID，但您的查询没有按 筛选ID，则 SQL 引擎将没有有效的方法直接遍历 B 树到您的查询筛选的行子集。