為什麼線上索引重建期間有2個分配單元到不同的文件組？
我正在將大表的聚集索引重建到不同的文件組。我正在使用
sys.system_internals_allocation_units. 我已經 3 小時了，但還沒有完成。奇怪的是，表中的分配單元似乎太多了！
- 舊文件組，IN_ROW_DATA（正常）
- 舊文件組，ROW_OVERFLOW_DATA（正常）
- 新文件組，IN_ROW_DATA（正常）
- 新文件組，ROW_OVERFLOW_DATA（正常）
- 新文件組，IN_ROW_DATA（再次！）
所以
IN_ROW_DATA目標文件組中有兩個！其中之一具有數據壓縮功能NONE，其中之一具有PAGE. 我正在做索引重建WITH (DATA_COMPRESSION = PAGE, ONLINE = ON)。該表未分區。你可以自己看看：
SELECT idx.name , au.allocation_unit_id, au.type_desc, au.container_id, au.filegroup_id, au.used_pages, au.root_page , par.index_id, par.rows, par.data_compression_desc FROM sys.system_internals_allocation_units au LEFT JOIN sys.partitions par ON (au.container_id = par.hobt_id AND au.type IN (1, 3)) OR (au.container_id = par.partition_id AND au.type IN (2)) LEFT JOIN sys.indexes idx ON par.object_id = idx.object_id AND par.index_id = idx.index_id LEFT JOIN sys.objects obj ON par.object_id = obj.object_id WHERE obj.name = 'X' ORDER BY obj.name, idx.name, par.partition_number, au.filegroup_id, au.type_desc
文件組 2 是目標。兩個
IN_ROW_DATA分配單元中都有很多頁面，因此它們中的一個不像是某種虛擬的。此外，該表佔用的空間是此時應佔用的空間的 2 倍以上。顯然，DATA_COMPRESSION設置沒有採取！**問題：**為什麼同一個分區有兩個分配單元？為什麼我的
DATA_COMPRESSION設置不會導致數據被壓縮？編輯：第 1 行和第 4 行似乎對應於相同的數據。它們都在目標中，並且具有相同的行數。似乎所有行都被寫入了兩次——一次壓縮，一次未壓縮。我可以確認正在使用該空間（或至少已寫入並標記為已分配）。
編輯 2：
INSERT我正在重建的表的 DML 計劃顯示插入3 個HOBT。不僅僅是線上索引重建期間預期的 2 個。沒有定義非聚集索引。這是計劃：
編輯 3：重建已完成。未壓縮的（巨大的）分區消失了。唯一剩下的是壓縮的。不幸的是，兩者的分配範圍在寫入過程中混合在一起。使用我編寫的視覺化工具，它看起來像這樣：
（這是整個分配點陣圖的<1%）。黑色 = 已分配，白色 = 空閒（以前是臨時分區）。
這對於順序 IO 來說是一個可怕的結果！因此，我將表切換為它的空副本，以便能夠對其執行
ONLINE = OFF重建到一個新的文件組（它是一個僅插入表，因此我可以隨時將其切換出去）。這解決了問題：該表現在是連續的，並且沒有看到臨時分區。儘管如此，問題仍然存在：為什麼
ONLINE = ONCI 重建會導致所有這些討厭的影響？如何解決？
臨時映射索引
創建、刪除或重建聚集索引的聯機索引操作也需要臨時映射索引。並發事務使用此臨時索引來確定在更新或刪除基礎表中的行時要在正在建構的新索引中刪除哪些記錄。此非聚集索引與新聚集索引（或堆）在同一步驟中創建，不需要單獨的排序操作。並發事務還在其所有插入、更新和刪除操作中維護臨時映射索引。
如果線上創建、重建或刪除聚集索引，則會創建臨時非聚集索引以將舊書籤映射到新書籤。如果 SORT_IN_TEMPDB 選項設置為 ON，則在 tempdb 中創建此臨時索引。如果 SORT_IN_TEMPDB 設置為 OFF，則使用與目標索引相同的文件組或分區方案。（我的注意：預設為關閉）
索引 ID 254 確實是映射索引。SQL Server 2005白皮書中的聯機索引操作有更多詳細資訊。