在討論索引碎片時，很多同學(xué)并不知道重建索引（ALTER INDEX ... REBUILD）和重組索引（ ALTER INDEX ... REORGANIZE）之間的區(qū)別，所以下面就是這篇文章的主題。以下所說的僅適用于基于行的索引（不是列存儲索引），同樣適用于聚集索引或非聚集索引。

空間需求

重建索引是要在刪除舊索引之后創(chuàng)建新索引，不管舊索引中存在多少的碎片。這意味著你需要有足夠的可用空間來容納新索引。

重組索引首先將索引行擠壓在一起以嘗試釋放一些索引頁，然后將其頁面重新調(diào)整，使其物理(分配)順序與邏輯(鍵)順序相同。這只需要一個 8KB 的頁面作為移動頁面的臨時存儲。因此，索引重組非常節(jié)省空間。

如果磁盤空間有限，對于分區(qū)表又無法利用單分區(qū)重建索引，則重組索引是比較好的方法。

算法速度

重建索引將始終構(gòu)建一個新索引，即使沒有碎片的索引（看你是否設(shè)置索引填充度）。重建所需的時間長度與索引的大小有關(guān)，而不是其中的碎片量。

重組索引只處理存在的碎片，碎片越多，重組所需的時間就越長。

這意味著對于碎片較少的索引（例如小于 30% 的碎片），重組索引通常會更快。但對于碎片較多的索引，通常重建索引會更快。所以我們通常設(shè)置， 0-5% 的碎片什么都不做，5%-30% 的碎片則重組索引，30%+ 重建索引。

生成的事務(wù)日志

在 FULL 恢復(fù)模式下，重建索引是完全記錄的，因此事務(wù)日志需要在單個事務(wù)中容納索引完整大小。這也意味著重建索引生成的事務(wù)日志可能需要進(jìn)行鏡像、發(fā)送到 AG 副本、復(fù)制掃描、備份等。

在 SIMPLE 和 BULK_LOGGED 恢復(fù)模式下，由離線重建索引生成的事務(wù)日志量將是最小的（在線索引重建總是完全記錄）——只是按頁面和區(qū)進(jìn)行分配。但是，下一次執(zhí)行日志備份（BULK_LOGGED 模式或切換到 FULL 模式）時也將包含重建更改的所有范圍，因此日志備份的大小與在 FULL 恢復(fù)模式下重建索引完成的大小是一樣的。這樣做的好處是，在單個事務(wù)重建索引期間，不用考慮事務(wù)日志有較大的增長。

而在所有的恢復(fù)模式中，重組索引都是完全記錄的，但只作為一系列小事務(wù)執(zhí)行，因此不會導(dǎo)致事務(wù)日志異常增長。當(dāng)然，事務(wù)日志僅為執(zhí)行期間生成的大小，所以重組索引可能會少一些，因為它只處理存在的碎片。

鎖請求

任何離線重建索引都持有表的架構(gòu)修改鎖(SCH-M)——不能更新或讀取整個表。

任何在線重建索引都會在操作開始時獲取一個短期共享表鎖，在整個操作過程中持有一個意向共享鎖（只會阻塞排他鎖和架構(gòu)修改鎖），然后在操作結(jié)束時獲得一個短期架構(gòu)修改鎖。從 SQL Server 2014 開始，你可以使用 WAIT_AT_LOW_PRIORITY 選項來延遲潛在的阻塞。

重組索引在整個操作過程中持有一個意向排他鎖，它只會阻塞共享、排他和架構(gòu)修改鎖。

是否可中斷

重建索引操作不能被中斷，它是原子性的，要么全有要么全無，除非你想撤銷并回滾該操作。但是在 SQL Server 2017 中，提供了一個可恢復(fù)的在線索引重建功能。

重組索引可以進(jìn)行中斷，前期處理的不會進(jìn)行回滾，最糟糕的情況只是對當(dāng)前正在進(jìn)行的單頁移動回滾。

是否報告進(jìn)度

重建索引沒有正確的進(jìn)度報告。你可以通過Profiler 事件 Progress Report: Online Index Operation 中的 bigintdata1 列來對在線索引操作進(jìn)行跟蹤，這顯示了舊索引的多少行已被掃描。你還可以通過查看 SPID 在sys.dm_exec_requests 中完成的頁面讀取次數(shù)推斷。

重組索引操作參考 sys.dm_exec_requests 的 percent_complete 列，你可以輕松地衡量其剩余的工作量。事實上，DBCC INDEXDEFRAG 也用于進(jìn)行進(jìn)度報告，但不太優(yōu)雅，它每 30 秒向你的連接打印一條進(jìn)度消息。

統(tǒng)計信息

重建索引將始終使用等效于完全掃描（或采樣，對于索引分區(qū)或索引已分區(qū)）重建索引列統(tǒng)計信息。

重組索引看不到索引的整體視圖，因此無法更新統(tǒng)計信息，這意味著需要手動維護(hù)索引統(tǒng)計信息。

總結(jié)

正如你所看到的，在重建和重組之間有相當(dāng)多的主要區(qū)別，但是對于你應(yīng)該使用哪一個并沒有正確的答案——那是你的選擇。

如果你的索引維護(hù)例程總是重新構(gòu)建而從不考慮重組，那么你應(yīng)該重新考慮。為了節(jié)省時間和資源，通常更好的做法是重新組織輕微碎片化的索引，并重新構(gòu)建嚴(yán)重碎片化的索引。

和往常一樣，我推薦Ola Hallengren的免費代碼，而不是編寫你自己的索引維護(hù)解決方案(是的，其他人也做過類似的工作，但我認(rèn)為Ola的代碼是迄今為止最好的、使用最廣泛的)。

閱讀原文：原文鏈接