欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

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

空間需求

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

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

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

算法速度

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

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

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

生成的事務日志

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

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

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

鎖請求

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

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

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

是否可中斷

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

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

是否報告進度

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

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

統計信息

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

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

總結

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

如果你的索引維護例程總是重新構建而從不考慮重組，那么你應該重新考慮。為了節省時間和資源，通常更好的做法是重新組織輕微碎片化的索引，并重新構建嚴重碎片化的索引。

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

閱讀原文：原文鏈接