為什麼我不定期執行“索引重組”？
到目前為止，我多次嘗試索引重組查詢。它們看起來像這樣：
ALTER INDEX ALL ON TableName REORGANIZE這樣的查詢可能需要幾個小時，但看起來它不會干擾其他數據庫操作。對於某些表，它的效果幾乎沒有，但對於某些表，它實際上節省了整個數據庫空間的 15%。
如果我每週左右對所有索引執行此查詢會怎樣？有什麼理由不這樣做嗎？
當您的索引中有大量空白時（即sys.dm_db_index_physical_stats DMV
avg_page_space_used_in_percent中的列），應該重新組織索引。SQL Server 社區中的許多人（甚至是解決方案）說您需要查看索引碎片級別（例如，在同一個 DMV 中），但這並不是一個重要的問題，具體取決於底層儲存的類型（例如任何 RAIDed無論如何，出於冗餘目的對您的數據進行分段）。其他人也得出了同樣的結論。avg_fragmentation_in_percent在不需要時重組索引的缺點是此操作將清除部分記憶體，以便它有足夠的空間在記憶體中執行重組。重組對記憶體的破壞性不如重建操作，但它們會降低您的頁面預期壽命 (PLE) 並可能清除您必須從磁碟重新讀取的有用數據（例如增加 I/O 操作）。此外，重組操作不會更新索引統計資訊。更新的統計資訊比碎片整理的索引更能產生最佳的執行計劃，所以如果你要盲目地執行夜間操作，我會說更新統計資訊是比重組實例更好的選擇。
正確的答案是讓解決方案在需要時檢查您的空白門檻值和重組/重建索引。讓另一個程序檢查您的統計數據並在需要時進行更新。有一些解決方案，例如Ola 的維護解決方案、Minionware 的 Reindex解決方案等。但我經常發現自己定制解決方案以滿足我的需求。
PS：John Eisbrener 的回答是一個很好的建議，我只想補充一點，您可能不會定期執行它的一個原因是 reorg/rebuild 會生成事務日誌。當然，任何主要的數據操作也是如此。
如果您正在執行日誌傳送環境，則傳送該期間的日誌備份可能需要更長的時間，這可能會對您的恢復點目標產生（並不總是成比例的）影響。
我當然見過這樣的例子，即 5 分鐘的索引重組在下一次備份中生成了 x GB 的日誌，這需要 y 分鐘來傳輸和恢復，其中 y > RPO。謝天謝地，到目前為止，我在這 y 分鐘內還沒有遇到實際的 DR 問題，所以我們一直都很好，但是接收所有這些 LSAlert 電子郵件（預設每 2 分鐘一次）並不有趣，因為要麼主伺服器沒有支持up 和/或輔助伺服器有一段時間沒有恢復。
此外，如果您在儲存空間緊張或單次 IO 成本較高的環境中執行，則額外的數據可能會影響成本層門檻值、最大化可用儲存或丟棄每晚的異地備份視窗。
有些人可能會爭辯說你不應該擔心這些事情，你應該只關心數據庫的性能如何，但我認為成本和可恢復性只是 n 維“良好狀態”集合中的附加維度’ 你的數據庫需要在其中才有用。
與往常一樣，它完全取決於您的環境中的邏輯或物理限制和/或您組織的需求和政治。