系統正常使用期間索引高度碎片化
我在我的項目中使用 MS SQL Server 2014 標準版，最近我遇到了在使用者正常使用系統期間索引碎片變高的問題。
目前索引在維護視窗期間每天重建一次，但在某些操作之後，一些索引會變得相當高（超過 30%）。另一個問題是，如果有大量數據要處理，碎片會發生在單個程序中，所以我們最終會得到一個啟動相當快的程序，但是一旦碎片開始，它的性能就會急劇下降。
在這種情況下我能做什麼？我不太可能獲得額外的維護視窗。我在考慮只定期重建一些索引，但我擔心它最終會導致數據庫鎖定甚至死鎖。
如果您可以正確確認碎片確實是一個問題，例如，因為當預讀變得不那麼有效時讀取性能會明顯下降，或者因為系統正在努力跟上頁面拆分的數量，您可能會考慮輕輕調整最關鍵索引的填充因子。這將提高寫入性能，但代價是讀取和可以記憶體的頁數（在標準版可用的有限緩衝池中）。
不要一開始就因為低填充係數而發瘋。選擇可管理數量的最有問題的索引，估計在維護視窗之間的正常工作負載期間避免過多拆分所需的可用空間量，並測試設置較低填充因子（通常不低於約 90第一次測試的百分比）。不要盲目地為所有索引設置較低的填充因子。
請記住，十有八九的系統存在其他更大的問題，而不是直接歸因於次優設置填充因子的問題。您應該監控系統的重要性能方面，並能夠根據對真實歷史數據的合理技術分析來為任何更改提出理由。
閱讀材料：
- 在產品文件中為索引指定填充因子
- 關於 Fillfactor的 5 件事 Kendra Little
- 索引填充因子會影響碎片嗎？埃里克·達林
- 別再擔心 SQL Server 碎片了，作者 Brent Ozar
- Eric Blinn在 SQL Server 中填充因子的最佳值是多少
- Ola Hallengren 的SQL Server 索引和統計資訊維護
一些選項：
只更新統計
您提到碎片會導致性能問題。很多時候，碎片似乎是問題，而實際上問題是糟糕的統計資訊（由於表中有多少數據發生了變化）。
您最好只更新所涉及表的統計資訊：
- 在這些大型操作之後，或
- 按計劃進行（每週、每天，甚至一天幾次 - 取決於問題出現的頻率）
重建索引會導致更新統計資訊，這可以強化碎片是問題的看法。與索引重建相比，這些操作的破壞性和資源密集度通常要小得多。
UPDATE STATISTICS dbo.YourTableName WITH FULLSCAN;您還可以使用“樣本百分比”來避免掃描整個表格：
UPDATE STATISTICS dbo.YourTableName WITH SAMPLE 50 PERCENT;測試不同的採樣率時要小心，因為有一個臨界點，採樣統計數據可能需要比
FULLSCAN. 這取決於多種因素（例如您的數據和可用資源）。Erin Stellato 在這裡有一篇關於這個主題的精彩文章：樣本量和更新統計的持續時間：重要嗎？避免造成碎片的常見原因
您可能能夠更改架構/工作負載以避免常見的碎片原因，從而在問題開始之前減慢或停止問題。首選範例是避免
uniqueidentifier通過 填充主鍵NEWID()。更一般地說，一個好的聚集索引應該是窄的、唯一的、靜態的和不斷增長的。
線上重建索引
如果在正常使用者活動期間重建索引非常重要，您可能必須嘗試證明昇級到 SQL Server 企業版的合理性。然後你可以指定索引重建發生在“ONLINE”：
ALTER INDEX [IX_YourIndex] REBUILD WITH (ONLINE = ON);這可以允許使用者活動在索引操作期間繼續，而不是在最後（應該是簡短的）。當然，重建仍然使用伺服器資源，因此可能會影響整體性能。
我把它放在最後是因為它上面有一個很大的價格標籤。在朝著這個方向前進之前，您絕對應該探索其他選項，並進行測試以確保
REBUILDs 確實可以解決問題。