从SQL Server 2000开始，“避免基于递增键创建聚簇索引”是神话吗？

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

数据库开发始于SQL Server 6.0。

从一开始就遵循的规则之一是，避免在这些索引优化技巧中找到基于递增键创建聚簇索引的方法。

现在使用SQL Server 2005和SQL Server 2008，给人留下深刻的印象，那就是情况已经改变。同时，这些主键列是表聚集索引的最佳首选。

神话可以追溯到SQL Server 6.5之前，后者添加了行级锁定。并由Kalen Delaney暗示。

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

发现金伯利·特里普（Kimberly L. Tripp）的权威文章

“聚集索引辩论仍在继续...”

热点是由于页面级别锁定而在SQL Server 7.0之前我们极力尝试避免的事情（这是热点一词成为否定词的地方）。实际上，它不必一定是负面的。但是，由于重新构造/重新设计了存储引擎（在SQL Server 7.0中），并且现在包含了真正的行级锁定，因此不再存在这种动机（避免热点）。

编辑，2013年5月

lucky7_2000的答案中的链接似乎表明，热点可能存在并且会引起问题。但是，本文在TranTime上使用非唯一聚集索引。这需要添加唯一符。这意味着索引不是严格单调增加的（并且太宽）。该答案中的链接与该答案或我的链接没有矛盾

在个人层面上，我已经在数据库中工作，我每秒将数万行插入到具有bigint IDENTITY列作为群集PK的表中。

综上所述，在现代的SQL Server版本中，如今，首选在标识列上使用群集键。

金伯利·特里普（Kimberly Tripp）撰写了一篇有关该主题的精彩博客文章。我可以解释一下，但请相信我，我不会公正地做。阅读。 http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

在那里，请查看她的其他一些有关集群键的文章。她的网站上有很多知识。

检查这篇文章：

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can-cause-latch-contention.aspx

基于递增键创建聚簇索引可能会创建不利于性能的热点...