向堆表中添加聚集索引
我注意到我們的數據庫上有一些堆表，它們在主鍵（它是一個 Int）上都有一個非聚集索引。最大的表有超過 200 萬行，轉發記錄數為 663,479，頁數為 609,028。還注意到伺服器上每秒轉發的記錄是 972。
從我有限的知識和一些Google搜尋來看，這一切看起來都很糟糕，所以我正在考慮向這個表添加一個聚集索引。
- 你同意這是正確的做法嗎？
- 如果是這樣，向該表添加聚集索引的最佳實踐是什麼，我假設我必須刪除主鍵上現有的非聚集索引（以及引用它的任何外鍵），然後添加聚集索引並重新創建外鍵鑰匙？是否有任何腳本可以幫助刪除和重新創建外鍵，因為有很多？
- 在等待整理索引的機會時，將重建堆作為短期修復是否有任何好處？
抱歉，如果我沒有提供足夠的資訊，請告訴我您是否需要知道其他任何可以提供幫助的資訊，謝謝！
你同意這是正確的做法嗎？
是的，特別是如果 (1) 使用主鍵查找表，並且 (2) 您注意到性能問題。
請注意，如果主要使用 PK 以外的一組數據查找表（例如：Order Lines 可能按 OrderID 查找並按 OrderLineId 排序），那麼您可以考慮基於最常見查找的聚集索引(s)，尤其是當他們選擇行序列時。例如，在上面的訂單行範例中，具有如下聚集索引：
CREATE CLUSTERED INDEX Idx_OrderID_OrderLineId ON OrderLines (OrderId, OrderLineId)將是檢索給定訂單的所有訂單行的最佳選擇。
此外，在某些情況下，具有非聚集覆蓋索引可能是最佳的。無論您對這些表做什麼，都需要密切關注性能。
如果是這樣，向該表添加聚集索引的最佳實踐是什麼，我假設我必須刪除主鍵上現有的非聚集索引（以及引用它的任何外鍵），然後添加聚集索引並重新創建外鍵鑰匙？是否有任何腳本可以幫助刪除和重新創建外鍵，因為有很多？
最佳實踐取決於對上述問題的回答。如果您確實想要一個聚集的 PK（因為這是通常引用表的方式，或者因為沒有可以創建的明確的可聚集索引），那麼您將需要執行上面指定的所有步驟。如果您決定創建一個與您的 PK 相同的聚集索引（是的，人們這樣做…），您將不需要執行所有這些步驟。如果您決定您的最佳聚集索引是與 PK 不同的欄位組合，那麼您也不需要執行所有這些步驟。
如果您確實將 PK 替換為集群 PK，那麼有一些腳本可以幫助辨識外鍵。我傾向於使用 SSMS 內部的 View Dependencies 功能來確定 FK 到我的表的可能位置，然後手動編寫腳本並自己刪除它們（因為我對應該處理 FK 的腳本有一些不好的經驗），所以我不能立即推薦任何特定的選擇。
在等待整理索引的機會時，將重建堆作為短期修復是否有任何好處？
不是真的，不。