爲插入/刪除優化SQL Server集羣密鑰

我有一些定期提供新數據的報告活動，我目前的策略是刪除舊數據然後插入新數據，我使用範圍查詢批量移動報告數據經過一段時間。爲插入/刪除優化SQL Server集羣密鑰

我的插入性能應該很好，因爲我在這裏所做的所有附加數量都在不斷增加，我使用datetime2(7)數據類型和sysdatetime()作爲默認值。

不過，我很擔心碎片問題。

舊數據將首先被寫入，但最終數據將被刪除，並且新數據（替換此數據）將被追加到最後。

我的數據在更新時應該有效地進入未來。

我完全除了所有舊數據最終被刪除。

我是否仍然需要擔心碎片或者會這樣做？我懷疑這會有很好的表現，但我仍然有些擔心SQL Server將無法回收已刪除的空間。

來源

2012-08-25 John Leidegren

我知道你會按聚簇索引順序插入和刪除。這種設計非常合理。過一段時間後，您仍然可能會對插入進行碎片化處理，因爲插入操作會重新使用已刪除的頁面。可能存在異常現象，例如單個頁面未被釋放或其他雜項頁面出現在用於插入的範圍內。從這個意義上說，分裂導致更多的分裂作爲一個隨機過程。

確保沒有碎片的唯一方法是粗略地對數據進行分區，並將每個分區放入新的文件組中。這可確保插入始終位於文件的末尾（無需放置它們）。而且，刪除操作最終會導致整個分區符合刪除條件。

你有非聚集索引嗎？它們也可能分散。

來源

2012-08-25 11:18:58 usr

好的，我明白了。顯然有很多事情需要考慮，但是你給了我一些有趣的想法。現在我正在研究集羣情況，但我可能會在以後的日子裏用我的方式處理索引碎片。 –

使用NCI的通知時，基本上有兩種類型：與CI（例如DateTime）和隨機（UserName，EMail，...）幾乎相同的排序順序。第一種會表現同樣的方式，第二種會破壞表演。注意，插入到CI和NCI會導致極度碎片化，因爲SQL Server可能會爲每個索引分配每個第二次擴展！（是的，這很愚蠢）。文件組再次拯救。 – usr

這真的是很好的建議，謝謝！在爲性能/可伸縮性設計數據庫時，如何處理這些問題必須要有技巧，您不會知道任何特別好的資源？或者更好地嘗試每種情況，因爲您必須知道數據才能做出這些決定？ –

爲插入/刪除優化SQL Server集羣密鑰

回答

相關問題