何時將身份列作為聚集索引是一個壞主意？

對我來說，這只是幾個月的 SQL Server 程式，所以我的知識在很多方面都不是很好。在一個已經存在的工作項目中，我遇到了許多帶有聚群索引的大型複合主鍵的表。從我收集到的資訊來看，具有聚集索引的大型列/複合列對性能的影響非常大，有時邏輯解決方案是標識列。但同時我也遇到過很多人對身份列的過度使用感到憤怒。

但是我從來沒有遇到過標識列是一個壞主意的例子。

最近我們已經標準化了每個表都應該有一個標識列作為聚集索引 - 無論我們是否將其用作 PK，因為我們需要它用於某些導出目的。

所以我想要一些例子，在現實生活場景中，使用標識列作為聚集索引是一個壞主意。

儘管有時它使我們的生活變得輕鬆，但我從未遇到過會被認為是不好的情況。

PS：我認為我的問題有點天真，但它讓我非常煩惱，所以我不得不問一下。

我通常使用標識列作為聚集主鍵。但是，在某些（罕見？）情況下，由於 LastPageInsertLatchContention，這並不理想。如果一個表被大量數據填充，就會發生這種情況。由於標識鍵，所有這些 INSERT 都想寫入表的最後一頁（索引）。所以這個頁面可以被鎖定，並且使用另一種解決方案性能可能會更好。

看

• http://dangerousdba.blogspot.ch/2011/10/bit-reversion.html
• http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can-cause-latch-contention.aspx
• http://www.sqlpassion.at/archive/2014/04/15/an-ever-increasing-clustered-key-value-doesnt-scale/

詳情。

引用自：https://dba.stackexchange.com/questions/68639