加速大型聚集索引的創建？

我有一張大表，表的行數超過 30 億，這張表的數據空間約為 120 GB。

以及 Intel Xeon CPU E5645 @2.4GHz（2 個處理器），24 個 CPU，64G 記憶體，64 位 windows server 2008 R2 企業版。

我跑

create unique clustered index MyTable_IXC on tblFactFoo(barKey) on [PRIMARY]

但是用了6個多小時（實際是6小時後報了duplicate key的錯誤）。

執行時cpu不到10%，磁碟IO不到20M/s，正常情況下15M/s左右，不知道用這麼強大的硬體如何提高創建聚集索引的性能。

您需要在查詢執行時查看等待類型。奇怪的是，您需要更快的磁碟，因為在一個很大的表上建構索引會導致大量的讀取和寫入。

簡而言之，您需要讀取 120 Gig 表，根據集群鍵對其進行排序（這將導致大量溢出到 tempdb 寫入可能 100 Gig 到 tempdb），然後將集群索引寫入數據庫導致 120 Gigs 的寫入。

最重要的是，表上的任何非聚集索引都需要同時重建，因此也需要讀取和重寫這些索引（以及重建非聚集索引所帶來的所有記憶體溢出）。

您可以通過禁用非聚集索引來加快速度，然後在重建聚集索引後手動建構它們。您需要確保最終使用者在建構非聚集索引時無法接觸系統，因為在創建非聚集索引之前，他們的查詢性能會很糟糕。

假設企業版可以創建常用的索引，然後讓使用者回來，然後線上創建其他索引，讓使用者工作。

無論您將看到一個非常長的維護視窗，您都將盡可能地猛烈撞擊磁碟。

這裡有幾點需要評估：

1. 打開數據壓縮：看起來你受 IO 限制並且有空閒的 CPU。數據壓縮在這裡可能是一個很好的權衡。
2. 打開SORT_IN_TEMPDB。這可以極大地改善 IO 模式（更多的順序 IO，以及最終索引中的更少碎片）。
3. 將索引建構到一個新的（預先確定的）文件組中。一個新的文件組沒有碎片化，所以你至少可以擺脫這個問題。使用即時文件初始化。

或者，首先載入正確排序的數據。那麼你根本不需要建立索引。這有一定的缺點，但值得考慮。ORDER最好的解決方案是使用批量載入提示載入到分區聚集索引中。每個分區一個批量導入流，每個 CPU 或每個物理磁碟一個分區。

引用自：https://dba.stackexchange.com/questions/41153