我真的需要一直在 SQL Server 中重新建構索引任務嗎？
我創建了 Re-build Index 任務，該任務將在每週日晚上 @11:00 PM 執行。
我沒有創建重新組織維護任務
- 我真的需要重建索引任務還是僅在碎片級別高於 30% 時才需要它？
- 當我有 Re-build Index Task 時是否需要 Re-Organize Index Task ？
我主要擔心的是，我們有完全備份恢復模式中的數據庫，並且 T-Log Auto-Growth 設置在 ‘%’ 中。
這佔用了我所有的 T-log 驅動器空間並為 SQL Server Functionality 造成混亂。
請指教 ？
我真的需要重建索引任務嗎
答案非常“取決於”。如果您的表中的數據隨著時間的推移沒有太大變化，那麼絕對不會，至少不會經常發生。
還是只有在碎片級別高於 30% 時才需要它？
在重建之前允許多少碎片是一門藝術而不是一門科學，並且可能取決於您的數據模式和性能指標+目標，但是如果只有非常少量的碎片，則絕對不需要重建大索引，所以在重建之前一定要檢查每個索引，看看它是否值得 IO 負載。
當我有 Re-build Index Task 時是否需要 Re-Organize Index Task ？
在重建的同時（之前或之後）進行重組是沒有意義的。與完全重建相比，重組是一項不那麼密集的操作，同時具有一些但不是全部的好處。如果你在重組後重建，那麼重組就被浪費了，因為整個結構都被扔掉了，如果你在之後重組，那麼這個過程就沒有什麼可以真正做的，所以它試圖做的任何事情都是浪費精力。
我主要擔心的是，我們有完全備份恢復模式中的數據庫，並且 T-Log Auto-Growth 設置在 ‘%’ 中。
我通常建議不要使用 % 增量，因為它們有時會產生大量不必要的增長。將增長設置為固定大小，相當大，因此不需要經常發生但不會太大。“合理”和“過度”的值將根據您的數據庫而變化。
這佔用了我所有的 T-log 驅動器空間
如果改變您的計劃以重建/重組/不那麼激進（即不每次都重建所有內容而不管目前的碎片），那麼也許您可以通過每天處理表的子集來分散一周的負載。如果您的數據庫有一個巨大的結構並且其餘數據位於非常小的表中（可能具有一個巨大的結果表和一系列小維度表的分析設置），這將幾乎沒有什麼區別，但否則可能是有益的。不過，首先嘗試將目前計劃更改為不那麼激進，這將更易於實現和維護，並且有許多範例腳本可供您根據數據庫的需要進行調整。
我要直截了當地說不，您不需要重建或重組索引。您可以只更新大多數係統上的統計資訊，而不會注意到差異。它可以對非常具體的工作負載產生影響。
不過，一般來說，使用非飛盤磁碟和相當大的記憶體塊，它不會讓您執行 Valhalla。
索引維護通常是一種非常昂貴且耗時的方法來改進一個指標：索引碎片百分比。我說這是一個曾經浪費大量時間試圖改進該指標的人。
它從來沒有完全解決任何問題，我也不確定是否所有花費在維護上的時間和資源都為我的查詢節省了相應的時間和資源。
一旦我停下來，我就有更多的時間和資源來處理更重要的事情，比如
DBCC CHECKDB.那麼什麼時候應該重建索引呢？幾乎永遠不會，除非您需要更改有關該索引的某些內容，例如填充因子、壓縮、分區對齊等。重建索引的一個好處是它們會更新統計資訊，但您可以單獨執行此操作。
什麼時候應該重組索引？也許偶爾，如果你真的想壓縮 LOB 數據。這樣做甚至不會更新統計數據，這很糟糕。
很多人認為重建索引可以解決性能問題的原因是因為他們所做的統計更新會使錯誤的查詢計劃無效。但同樣，您可以做到這一點，而無需將驅動器的鼻涕從驅動器中剔除，並且只需更新統計資訊即可耗盡空間。