具有代理標識鍵的聚集索引的填充因子的正確值
我有一個大表，它有一個帶有標識主鍵的聚集索引。我正在確定此表的填充因子的正確值，以最大程度地減少頁面拆分。我們使用每天執行的腳本來維護索引，該腳本會測量碎片並採取適當的措施。該表包含可變長度列。
我的第一個想法是將其設置為 100（因為記錄應該只寫入表的末尾），但我認為對可變長度列的更改也可能導致頁面拆分，所以我現在轉向 90。
任何建議表示讚賞。
這取決於
這是一個平衡的行為。如果您的表是讀取密集型的，沒有太多更新或刪除，那麼預設值（即 100）應該沒問題。
如果您的表是寫密集型的，有很多更新，那麼低於 80 的值可能更合適。
這些東西沒有神奇的公式。（AFAIK，如果有請告訴我）最好的辦法是有一個測試環境，有一些工作量來測試。進行更改並查看您的數據庫如何處理工作負載。
尼克說得很對。
如果您進行更新以增加打包頁面上記錄的大小，那麼您將導致頁面拆分，但除此之外，使用標識主鍵不會導致聚集索引中的頁面拆分。
（雖然這樣說，儲存引擎可以執行 5 種類型的頁面拆分，但並非所有這些都會導致碎片和數據移動——當您插入單調遞增的標識值時，您得到的一種是頁尾拆分。但是我跑題了……）
我已經幫助了很多客戶，並且我圍繞它編寫了 BOL——如果你只想選擇一個值作為基礎，70% 的客戶取得了最大的成功。正如尼克所說，進行適當的監控和調整。
為任何索引選擇填充因子是一種平衡行為，即發生了多少將頁面填充度推向 100% 的活動，以及您可以多久採取一次糾正措施來重置填充因子。如果您將填充因子設置得非常低，例如 50%，您需要考慮最初會在頁面上“浪費”多少空間，但我再次看到這在某些情況下是合適的。
您還應該考慮如何使用索引。如果它只是用於單例查找，您可能會獲得較低的填充因子和更多的重建/碎片整理時間，因為您不會因為記憶體中有大量稀疏填充的聚集索引而浪費太多的 IO/記憶體。對於進行大範圍掃描，您希望填充因子稍高一些，以提高 IO 和記憶體效率。
還有 OLTP 與 DW 的問題 - 通常 DW 是不變的，因此索引將具有 100% 的填充因子。OLTP 是最難的部分。
整理完聚集索引後，請記住非聚集索引也需要注意，因為它們很可能會變得碎片化。
重置填充因子時，請記住您可以在重建和碎片整理之間進行選擇。DBCC INDEXDEFRAG/ALTER INDEX … REORGANIZE 在某些情況下可以為沒有嚴重碎片的索引重置填充因子。
希望這可以幫助！
（對不起’過度回答’ - 我的一個熱鍵，已經編寫了程式碼:-)