sql - 在 SQL Server 上将堆索引转换为聚集索引会产生什么后果？

Question

我最近收到建议，我应该将所有表从使用堆索引转换为每个表都有一个聚集索引。实行这一策略会产生什么后果？例如。定期重组数据库更重要吗？数据增长？插入速度太慢有危险吗？如果 PK 是 GUID，会有页面碎片整理的危险吗？ 我的应用程序速度显着提高？ 您的体验如何？

为了给好的答案提供灵感，以下是我从 stackoverflow 上的其他帖子中收集到的一些“事实”

1. 几乎肯定希望在数据库中的每个表上建立聚集索引。如果一张 table 没有。最常见查询的性能更好。
2. 聚集索引并不总是对 GUID 不利...这完全取决于应用程序的需求。 INSERT 速度会受到影响，但 SELECT 速度会提高。
3. GUID 字段中的聚集索引的问题在于 GUID 是随机的，因此当插入新记录时，必须移动磁盘上的大部分数据才能将记录插入表的中间。
4. 在 GUID 有意义并通过将相关数据彼此靠近放置来提高性能的情况下，GUID 上的聚集索引是可以的 http://randommadness.blogspot.com/2008/07/guids-and-clustered-indexes.html
5. 聚集不会影响查找速度 - 唯一的非聚集索引应该可以完成这项工作。

Answer 1

如果您的键是 GUID，那么其上的非聚集索引可能与其上的聚集索引一样有效。这是因为在 GUID 上，您绝对无法对它们进行范围扫描(“b4e8e994-c315-49c5-bbc1-f0e1b000ad7c”和“3cd22676-dffe-4152-9aef-54a6a18d32ac”之间可能有什么可能)意思是？？)。 GUID 聚集索引键的宽度为 16 字节，比从堆中获取的行 id 更宽，因此 PK guid 上的 NC 索引实际上是可以在讨论中辩护的策略。

但是将主键设为聚集索引键并不是在堆上构建聚集索引的唯一方法。您是否有其他频繁查询请求特定列的范围？典型的候选列是诸如 date、state 或 deleted 之类的列。如果这样做，那么您应该考虑将这些列设置为聚集索引键(它不必必须是唯一的)，因为这样做可能有助于请求范围的查询，例如“昨天的所有记录”。

堆具有显着性能优势的唯一场景是插入，特别是批量插入。如果您的插入负载不重，那么您绝对应该选择聚集索引。请参阅Clustered Index Design Guidelines .

回顾一下你的观点:

Almost certainly want to establish a clustered index on every table in your database. If a table does not have one. Performance of most common queries is better.

能够满足大多数查询的范围要求的聚集索引将显着提高性能，这是真的。可以满足顺序要求的聚集索引也很有帮助，但没有什么比可以满足范围的聚集索引更有用的了。

Clustered indexes are not always bad on GUIDs... it all depends upon the needs of your application. The INSERT speed will suffer, but the SELECT speed will be improved.

仅改进探测 SELECT:SELECT ... WHERE key='someguid';。通过对象 ID 和外键查找进行的查询将从该聚集索引中受益。 NC 索引也可以达到相同的目的。

The problem with clustered indexes in a GUID field are that the GUIDs are random, so when a new record is inserted, a significant portion of the data on disk has to be moved to insert the records into the middle of the table.

错了。插入索引中的位置不需要移动数据。最糟糕的情况可能是页面拆分。页面分割(不知何故)成本高昂，但并不是世界末日。您的评论建议必须移动所有数据(或至少“重要”部分)以便为新行腾出空间，这远非事实。

Clustered index on GUID is ok in situations where the GUID has a meaning and improves performance by placing related data close to each other http://randommadness.blogspot.com/2008/07/guids-and-clustered-indexes.html

我无法想象 GUID 可以拥有“相关数据”的场景。 GUID 是典型的随机结构，两个随机 GUID 如何以任何方式关联？ Donald给出的场景有一个更好的解决方案:Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads ，它的实现成本更低(所需的存储空间更少)，并且也适用于唯一键(链接文章中的解决方案不适用于唯一键，仅适用于外键)。

Clustering doesn't affect lookup speed - a unique non-clustered index should do the job.

对于探针(查找特定的唯一键)是的。 NC 索引几乎与聚集索引一样快(NC 索引查找确实需要额外的键查找来获取其余列)。聚集索引的亮点在于范围扫描，因为聚集索引可以覆盖任何查询，而可能可能满足相同范围的NC索引可能会在上丢失覆盖范围并触发Index Tipping Point .