Sql-Server
“避免基於遞增鍵創建聚集索引”是 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。