SQL Server 聚集索引、索引平衡和使用 NewID 的插入性能
我有一個大 (6db) 跟踪表。它有一個通過 GETDATE() 創建的集群鍵 (DateTime)。
在一個由 10 台電腦組成的集群中，用於連接到該數據庫/表的連接池平均高達 50 個，因此我們平均有大約 500 個並發連接嘗試插入。
數據庫適合記憶體，幾乎看不到任何 IO。
我試圖弄清楚在持續的 INSERT 負載下，聚集索引是否達到重新平衡樹的點，以及這是否會導致系統可以維持的插入數量減慢。
關於重新平衡索引是否是 SQL Server 在聚集索引（甚至是非聚集索引）上所做的事情，我心中有一些疑問。
問題-
- 插入性能的周期性/循環減慢是否有任何原因？
- 重新平衡操作是否會在聚集索引上自動觸發？
- 重新平衡操作是否會在非聚集索引上自動觸發？
其他資訊
- SQL Server 2008
- 非常大的伺服器 - 256Gb，40 核，40mbit LAN…
插入性能的周期性/循環減慢是否有任何原因？
是的。檢查點事件。正如您所描述的，在寫入密集型工作負載、大型 RAM 伺服器的情況下，大量“臟”頁面會在記憶體中累積。在預定的檢查點間隔，所有這些臟頁都被寫入磁碟，導致 IO 請求激增。這反過來會減慢日誌送出寫入的速度，這表現為您定期觀察到的 INSERT 響應時間的增加。QED。當然，這只是猜測，缺乏適當的調查。要獲得更確定的響應，我建議您閱讀如何分析 SQL Server 性能並應用其中描述的技術來辨識問題。
如果問題確實是由檢查點引起的，那麼 SQL Server 2012 帶有間接檢查點：
SQL Server 2012 中新增的間接檢查點為自動檢查點提供了可配置的數據庫級替代方案。… 間接檢查點通過在後台不斷將臟頁寫入磁碟來減少與檢查點相關的 I/O 尖峰。
有關檢查點對性能的影響的更詳細討論，請閱讀 SQL 問答：優化性能的微調：
尋找尖峰
Q. 我正在解決一個問題，即我們看到來自我們的一個 SQL Server 的周期性 I/O 尖峰。我已經使用 PerfMon 將其縮小到檢查點，但我不知道哪個數據庫是罪魁禍首。如何進一步鑽取？
在 SQL Server 2012 之前，您可以選擇減少恢復間隔值。這將增加檢查點的頻率，但會減少每個檢查點必須寫入的髒頁數。分散數據 IO 有助於（購買更多主軸）。將日誌 IO 分離到它自己的路徑（自己的主軸）對檢查點沒有幫助，但會將日誌送出與影響隔離開來，從而保持 INSERT 響應。SSD 創造奇蹟。
我建議不要進行任何結構性改變。在我看來，您已經擁有時間序列的最佳聚集索引。任何結構變化都必須得到根本原因-績效分析的支持，指出目前結構存在問題。