ALTER INDEX REORGANIZE 問題
我很少有索引高度碎片化（超過 90% 碎片化）且大小足夠大（數十 GB）的表。對這些進行碎片整理的目標是減少上述表格的空間消耗。
我想避免執行 REBUILD 操作，因為它太耗費資源。還試圖避免記錄到事務日誌和日誌增長，以及因此導致大的事務日誌備份大小。
這就是為什麼選擇 REORGANIZE 操作而不是 REBUILD 來處理高碎片的原因。
關於 REORGANIZE，有以下問題：
- 如果同時在單獨的索引上執行多個 REORGANIZE 操作（比如 10+，在單獨的 SSMS 視窗/會話中） - 它會導致數據損壞或任何其他已知問題嗎？
- REORGANIZE 操作是否以任何方式/根本記錄到事務日誌？
- REORGANIZE 持有什麼樣的鎖？哪些查詢會因此受到影響？
在我的案例中，進行碎片整理的唯一原因是減少儲存空間消耗，它確實有幫助（例如索引之前是 18 GB，然後變成了 8 GB，等等）。就我而言，這比訂購額外的儲存空間更容易。
如果同時在不同的索引上執行多個 REORGANIZE 操作（比如 10+，在不同的 SSMS 視窗/會話中） - 它會導致數據損壞或任何其他已知問題嗎？
不，它不會。關於任何其他問題，如果您的 SQL Server 已修補到最新的 SP 和 CU，那麼您應該非常安全。
REORGANIZE 操作是否以任何方式/根本記錄到事務日誌中？
是的，他們實際上記錄在所有恢復模式中。引自SQLskills.com
在所有恢復模式中，重新組織索引都是完全記錄的，但作為一系列小事務執行，因此不應導致事務日誌過度增長。當然，事務日誌只為執行的操作生成，對於重組來說可能更少，因為它只處理存在的碎片。
REORGANIZE 持有什麼樣的鎖？哪些查詢會因此受到影響？
再次引用上面分享的 Paul Randals 部落格
索引重組在整個操作過程中都持有一個意圖排他表鎖，它只會阻止共享、排他和模式修改表鎖。我為 SQL Server 2000 編寫 DBCC INDEXDEFRAG 的主要原因之一是作為 DBCC DBREINDEX 的線上替代品。
還試圖避免記錄到事務日誌和日誌增長，以及因此導致大的事務日誌備份大小
請注意，如上所述，索引重組已完全記錄，因此會生成日誌，但由於 SQL 引擎一次只在一個數據庫頁面上工作，因此日誌增長不會過度膨脹並且會受到控制。