非集羣索引表上的性能問題

我們有一張約有100,000條記錄的表，這個記錄在我們的應用程序中經常使用。我們有一個身份（ID）列，並有一個聚集索引，並且一切運作良好。但由於某些原因，我們不得不使用Uniqueidentifier列作爲主鍵。因此，我們在其上添加一個非聚集索引並刪除ID列上的聚集索引。但是現在，我們在高峯時期有很多客戶的性能下降問題。是否因爲表格現在沒有聚集索引？非集羣索引表上的性能問題

來源

2012-07-12 user1023137

它取決於您用來訪問數據的查詢。爲什麼不把UniqueIdentifier作爲主鍵？ – PraveenVenu 2012-07-12 06:07:34

Guid列現在是主鍵，它具有非聚簇索引 – user1023137 2012-07-12 06:11:30

您是否明確地將其設爲非聚簇？ PK默認爲聚簇索引。 – PraveenVenu 2012-07-12 06:15:15

您添加主鍵的事實決不意味着您必須刪除聚集索引。這兩個概念是不同的。您可以使用由非聚集索引和單獨的聚集索引（例如舊的ID列）實現的uniqueidentifier PK。

但真正的問題是當您添加唯一標識符PK時，您是如何更改應用程序的？您是否還修改了應用程序代碼以通過此新PK（通過uniqueidentifier）檢索記錄？你是否更新所有連接來引用新的PK？您是否修改了引用舊ID列的所有外鍵約束條件？或者應用程序是否繼續使用舊標識ID列檢索數據？我的期望是，您更改了這兩個應用程序和表，並且訪問現在流行的形式爲SELECT ... FROM table WHERE [email protected]。如果只有發生此類訪問，那麼即使使用非羣集uniqueidentifier主鍵並且沒有聚簇索引，該表也應該執行OK。所以必須有別的東西在起作用：

您的應用程序將繼續按照舊標識ID列
有你的查詢連接基於舊的身份ID列
有訪問表引用舊的ID列上的表的外鍵約束

最終，您將遇到性能問題疑難解答問題，並將其視爲性能問題排查問題。我有兩個很好的資源給你： Waits and Queue methodology和Performance Troubleshooting Flowchart

來源

2012-07-12 06:37:55

是的，我們修改了我們的應用程序並寫了千行的腳本（！）來更新所有其他表和關係，我們沒有放棄ID列，但放棄了聚集索引，它在系統正常情況下正常工作，但在高峯時間，它是真正的很慢。非常感謝你提供有用的鏈接。我將閱讀它們，並再次詢問問題是否會延長:) – user1023137 2012-07-12 08:40:14

嗨我認爲你可以使用NEWSEQUENTIALID（）而不是NEWID（）將uniqueidentifier列作爲聚簇索引。隨着newsequentialid生成序列ID和聚簇索引，它是最好的。

來源

2012-07-12 09:06:57 AnandPhadke

非集羣索引表上的性能問題

回答

相關問題