选择什么列来创建聚集索引答案

【问题标题】：What column choose to create clustered index选择什么列来创建聚集索引
【发布时间】：2018-12-14 11:50:34
【问题描述】：

我有一个包含超过 2500 万行的表。该表每天都在变大（大约 35 000 行）。我在 2 列上创建了非聚集索引 - 日期和债务 ID（这些列在 WHERE clouse 中最常用），每个债务 ID 在每个日期仅出现一次）。所以表仍然是堆，因为它没有聚集索引。您认为添加标识列 (1,1) 并在其上创建聚集索引是个好主意吗？或者你认为我应该怎么做才能提高这张桌子的性能？

【问题讨论】：

如果没有其他需要考虑的事情，我建议将您已经存在的索引转换为集群索引。
但是，如果我将非聚集索引转换为聚集索引，它就不会在带有 WHERE clouse 的查询中使用？我是对的，不是吗？
不，你不是。实际上，如果一个表只有一个聚集索引和 0 个非聚集索引，那么每个查询都会使用聚集索引。只需确保使用与索引键相同的 2 列，这样您的 where 就会从查找中受益。如果您需要未包含在非聚集索引中的列，这些查找可能会比以前更快。
所以@George，您认为创建聚集索引添加标识列没有意义？
我忘记了 ID 部分。好吧，我当然不能回答这个问题；这是一个深度设计选择，有很多优点、很多缺点和大量讨论。第一次谷歌搜索引导我到这里：en.wikipedia.org/wiki/Surrogate_key

标签： sql-server tsql

【解决方案1】：

如果您的两列在任何情况下都是唯一的，则可以将它们用作聚集索引。

最重要的是：聚集索引不应更改其值，并且应以正确的顺序附加新行。

将DATETIME2 作为聚集索引的第一列插入的时间在这里是一个不错的选择。
必须通过此值和您提到的debt_id 的组合来保证唯一性。
假设插入时间和debt_id都没有更改数据，这看起来是一个非常好的组合PK。

否则您的聚集索引可能会得到fragmented。这会使事情变得更糟......（UNIQUEIDENTIFIER ID 往往作为集群 PK 非常糟糕的主要原因。定期运行索引修复脚本可能是一种可接受的解决方法。）

只要您的查询过滤两列（至少必须涉及第一个列），非分段聚集索引就会加快速度。

您可以添加更多索引，甚至可以为它们添加大量需要的值 INCLUDE。

其他索引将使用聚集索引作为查找（在构建聚集索引后可能需要重新创建）。如果聚集索引表现良好，这会有所帮助，否则会使事情变得更糟。

所以我会说：如果上述情况在您的情况下属实，那么额外的ID IDENTITY 将无济于事。这将为每个查询增加一个步骤，因为查询将需要额外的查找。但是，如果索引容易出现碎片，我宁愿添加额外的 ID。最后，引用 cmets 中的 George Menoutis

好吧，我当然不能回答这个问题；这是一个深刻的设计选择大量的优点，大量的缺点和大量的讨论

在不了解您的数据库和您的需求的情况下，这纯属猜测......

【讨论】：