“避免基于递增键创建聚集索引”是 SQL Server 2000 天以来的神话吗？

Question

我们的数据库由许多表组成，其中大多数使用整数代理键作为主键。这些主键中约有一半位于标识列上。

数据库开发始于 SQL Server 6.0。

从一开始就遵循的规则之一是，避免根据递增键创建聚集索引，正如您在这些索引优化技巧中找到的那样。

现在使用 SQL Server 2005 和 SQL Server 2008，我强烈的印象是情况发生了变化。同时，这些主键列是表的聚集索引的完美首选。

Answer 1

这个神话可以追溯到 SQL Server 6.5 之前，它添加了行级锁定。并由卡伦德莱尼在这里暗示。

这与数据页使用的“热点”以及整个 2k 页（SQL Server 7 和更高版本使用 8k 页）被锁定的事实有关，而不是插入的行 Edit，2012 年 2 月

找到 Kimberly L. Tripp 的权威文章

热点是我们在 SQL Server 7.0 之前极力避免的东西，因为页面级锁定（这就是热点一词变成了否定词的地方）。事实上，它不一定是一个否定词。但是，由于存储引擎经过重新架构/重新设计（在 SQL Server 7.0 中）并且现在包括真正的行级锁定，因此这种动机（为了避免热点）不再存在。

编辑，2013 年 5 月

幸运7_2000 的答案中的链接似乎说热点可能存在并且它们会引起问题。但是，文章在 TranTime 上使用了非唯一聚集索引。这需要添加一个唯一标识符。这意味着索引不是严格单调增加（而且太宽）。该答案中的链接与此答案或我的链接不矛盾

在个人层面上，我在数据库中醒来，我每秒将数万行插入到一个表中，该表有一个 bigint IDENTITY 列作为集群 PK。

Answer 2

总而言之，在现代 SQL Server 版本中，标识列上的群集键是当今的首选选项。

Answer 3

Kimberly Tripp 有一篇关于这个主题的精彩博客文章。我可以解释，但相信我，我不会公正地解释。读一读。 http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

在那里，查看她关于集群键主题的其他一些帖子。她的网站可以提供丰富的知识。