這裏對現有的表的索引是該方案：更改SQL Server 2000中
的SQL Server 2000（8.0.2055）
表目前有4.78億行數據。主鍵列是具有IDENTITY的INT。有一個唯一約束施加在其他兩列與一個非聚集索引。這是一個供應商應用程序，我們只負責維護數據庫。
現在的廠商建議做以下「提高性能」
我不相信這是正確的做法。我有一些擔憂。
通過刪除PK和索引，您將創建一個包含4.78億行數據的堆。然後在兩列上創建一個CLUSTERED INDEX將是一項非常艱鉅的任務。會創建另一個具有相同結構和新索引方案的表格，然後複製數據，刪除舊錶格並重命名新表格是一個更好的方法？
我也不確定存儲過程如何反應。考慮到它們沒有被明確重新編譯，它們會繼續使用緩存的執行計劃嗎？
我根本無法理解此更改會提供哪種「性能改進」。我認爲這實際上會有相反的效果。
歡迎您的光臨。
由於提前，
拉吉
所有存儲的特效會自動重新編譯。無論如何，當統計信息發生變化時以及索引維護之後，這將會發生。
在某些情況下，您必須重新組織4.78億行（放置/創建索引）或移動（新表格）。不幸的是，兩種方式都不如其他方式更好。不過，我感覺到你的痛苦：我們有類似的大表，有新的列和索引更改。
說到這一點，您應該執行步驟2-1-4-3，以避免在刪除/創建聚簇索引時進行不必要的非聚簇索引維護。
並放棄唯一約束。聚集索引可以是唯一的和聚集的。一個獨特的constrint只是另一個不必要的索引。
至於性能方面的好處，可能要問供應商爲什麼。
會創建具有相同結構和新索引方案的另一個表，然後複製數據，刪除舊錶並重命名新表成爲更好的方法？
我相信，這是SQL企業管理器將在幕後執行的操作，無論如何，如果您使用可視化工具來執行此操作。如果您進行模式更改（例如在表格中間添加列）或更改主鍵，則會出現一個小按鈕，可讓您執行「腳本更改」。如果您查看此腳本，您可以看到企業管理器爲執行您的請求而採取的步驟。
如果你有空間問題（我在這裏說的是事務日誌），創建一個新表並在一個時間塊上覆制數據塊可能是一個有效的選擇，但是寫起來很棘手，需要更長的時間才能運行。另外，我發現，當你熟悉你的模式，數據和硬件時，編寫更好的代碼並不比編寫EM和SSMS的萬能代碼更難。 – 2010-04-13 20:13:37
我會認真看待的一件事是什麼類型的其他兩列是什麼 - 他們有多大，與INT IDENTITY（4字節）？
我之所以問：在聚集鍵將被添加到上表中的所有非聚集索引，太 - 如果你有接近500萬行，這將使巨大的差異是否聚類密鑰是單個4字節的INT，或者例如兩個16字節的GUID。
這不僅在磁盤上，請注意 - 頁面全部加載到SQL Server的RAM中 - 因此，由於可能會增加集羣密鑰，由於磁盤上的頁面數量較多，您會受到性能損失（和RAM），你的非聚集索引將需要。
我可以看到實際完成這些更改的唯一令人信服的理由是，如果通過使用這兩個其他列對錶進行聚類，您將在查詢性能方面獲得一些好處，例如，如果某些最頻繁的查詢會更快，這是由於該表現在由這兩列進行聚類。這真的很難知道，除非你知道訪問和查詢模式真的是什麼......
其中一列是int，另一列是日期時間。 – Raj 2010-04-13 21:11:51
謝謝。從停機的角度來看，哪種方法更好？ – Raj 2010-04-13 19:51:48
我傾向於刪除/創建索引...但是，有4.78億行，你可能只是做它，而不是測試它，也許:-) – gbn 2010-04-13 19:54:09
確保你有足夠的磁盤空間：2 x表空間左右重建一個聚集索引將從...複製數據到...），1.5到2個索引空間（如果可以的話，設置在tempdb中排序），我認爲事務日誌文件也有一個命中。如果您的測試設置足夠大，請首先嚐試一下，以便估計您的生產宕機時間。 – 2010-04-13 20:09:02