索引重建時間是否取決於碎片級別？
索引重建所需的時間是否取決於碎片級別？
如果重建 40% 碎片化的相同索引需要 1 分鐘，重建 80% 碎片化索引是否大約需要 2 分鐘？
我要求的是執行所需操作可能需要的 RUNTIME（例如以秒為單位），而不是關於在什麼特定情況下需要哪個操作。我知道應該進行索引重組或重建/統計更新時的基本最佳實踐。
這個問題沒有詢問 REORG 以及 REORG 和 REBUILD 之間的區別。
背景：由於設置了不同的索引維護工作（每天晚上，週末更繁重的工作……）我想知道是否應該對中低碎片索引更好地執行每日“輕度”離線索引維護工作以保持關閉時間很小 - 或者它甚至無關緊要，並且在 80% 碎片索引上的重建可能需要與在相同索引 40% 碎片上的相同操作相同的關閉時間。
我遵循了這些建議，並試圖找出自己發生了什麼。我的實驗設置：在測試伺服器上什麼都不做，並且沒有被任何人或其他任何人使用，我在唯一標識符主鍵列上創建了一個帶有聚集索引的表，其中包含一些附加列和不同的數據類型
$$ 2 numerics, 9 datetime, and 2 varchar(1000) $$並簡單地添加了行。對於提出的測試，我添加了大約 305,000 行。 然後，我使用更新命令並隨機更新了對整數值進行過濾的一系列行，並使用不斷變化的字元串值更改了其中一個 VarChar 列以創建碎片。之後，我檢查了目前
avg_fragmentation_in_percent級別sys.dm_db_index_physical_stats。每當我為我的基準創建一個“新”碎片時，我都會添加這個值，包括physical_page_count我的記錄中的值，如下圖所示。然後我跑了：並通過使用到我的錄音中
Alter index ... Rebuild with (online=on);抓住了。CPU time``STATISTICS TIME ON我的期望：我希望至少能看到一種線性曲線的跡象，顯示碎片級別和 CPU 時間之間的依賴關係。
不是這種情況。我不確定這個程序是否真的適合獲得好的結果。也許行數/頁數太少？
然而，結果表明我原來的問題的答案肯定是NO。看起來 SQL Server 重建索引所需的 CPU 時間既不取決於碎片級別，也不取決於基礎索引的頁數。
第一個圖表顯示了重建索引所需的 CPU 時間與之前的碎片級別相比。正如您所看到的，平均線是相對恆定的，並且碎片和所需的可觀察 CPU 時間之間根本沒有關係。
為了尊重更新后索引中頁數變化可能需要更多或更少時間來重建的可能影響，我計算了 FRAGMENTATION LEVEL * PAGES COUNT 並在第二張圖表中使用了這個值，該圖表顯示了所需 cpu 時間的關係與碎片和頁數相比。
如您所見，這也並不表示重建所需的時間會受到碎片的影響，即使頁面數量有所不同。
在做出這些陳述之後，我想我的程序一定是錯誤的，因為重建一個巨大且高度碎片化的索引所需的 cpu 時間可能只受行數的影響——我並不真正相信這個理論。
所以，因為我現在真的很想知道這一點，所以非常歡迎任何進一步的評論和建議。
索引重建所需的時間是否取決於碎片級別？
我相信這不會是 SQL 伺服器決定並需要時間重建\重新組織索引的主要參數：
基於“數據”還涉及各種其他因素，通過這些因素決定需要多長時間：參數如
因素 1：表大小
因素 2：可用性問題
因素 3：分區
因素 4：索引列和唯一性
如果您想了解更多關於這些因素的資訊，可以參考這裡。
如果重建 40% 碎片的相同索引需要 1 分鐘，重建 80% 碎片索引是否需要 2 分鐘？
再次，答案可能是它取決於！對於數字，您將需要測試場景並查看輸出結果。跟踪諸如 FRAG 級別 80 的詳細資訊，重建耗時 X 小時\分鐘\秒，對於 Frag 級別 40，重建耗時 Y 小時\分鐘\秒。計算並保留超過 15 天的歷史記錄（取決於計劃的維護活動），您可以得出比較兩者實際花費的時間的結論。
此外 ：
您可以收集有關索引重建進度的數據\計算：
使用 DMV sys.dm_exec_requests 或
如果您有 Ola 的 Re-indexing-Re-organizing 維護計劃，則可以選擇將維護期間執行的操作的歷史記錄保存在表 CommandLog 中，如SQL Server Index and Statistics Maintenance中所述。保存數據後，您可以查詢命令類型“ALTER_INDEX–REBUILD”以及 START TIME 和 END TIME 列之間相同的差異