由於使用GUID（uniqueidentifier）而導致的數據庫修改

我已經完成的應用程序已經上線，並且就特定表格中的響應時間而言，我們正面臨一些非常具體的問題。由於使用GUID（uniqueidentifier）而導致的數據庫修改

簡而言之，某些具有5k行的表的響應時間非常短。而這些表格的規模會越來越大。

這些表中的一些（例如Order Header表）具有與P.K.相同的唯一標識符。我們認爲這可能是響應時間較短的原因。

在研究的情況下，我們已經決定下列選項

我們認爲，選擇2號是理想的，因爲選擇3號需要大票變化。

但要實現我們需要將插入存儲過程中的一些處理移動到觸發器。這是因爲我們需要從OrderHeader表中捕獲PK，並且我們無法使用

在插入存儲過程中選擇@OrderID = newsequentialid（）。

而如果我們繼續把處理轉移到觸發器，我們可以使用

從插入

選擇的OrderID現在的問題嗎？

感謝噸

羅米

2011-05-25 Romi24

5k行是TINY !! – 2011-05-25 09:38:12

你爲什麼認爲它的問題是問題？聽起來很奇怪。你知道女巫查詢數據庫是慢嗎？你有沒有分析過這個問題？你檢查執行計劃嗎？你可以發佈「問題」查詢，以便我們可以分析PK是否真的是問題？ – Ivo 2011-05-25 09:41:26

將表OrderHeader中的主鍵索引轉換爲非集羣索引。

似乎是一個很好的選擇，無論你做什麼。如果您的表使用pkey進行聚簇，而後者是UUID，則意味着您不斷在表的中間寫入某個位置，而不是將新行添加到該表的末尾。僅此一項就會導致性能下降。

建議使用對排序實際有用的索引對錶進行聚類;理想情況下日期字段上的東西，不太理想（但仍然非常有用）標題/名稱等。

2011-05-25 09:42:35

無論如何我會這樣做。但重點是在我將索引轉換爲非集羣索引之後，是否需要使用newsequentialid（）而不是newid（）？或者只是將索引更改爲非聚集索引就足夠了？ – Romi24 2011-05-25 09:46:15

newsequentialid（）而不是newid（）意味着你將擁有更少的隨機uuids，但它們仍會隨機將你置於桌子中間。你真正的問題是，由於在某些內在隨機的情況下聚集，你的行在表中的所有位置（導致大量的隨機磁盤搜索）。 – 2011-05-25 09:48:54

（關注）如果您的日期與訂購標準以及插入順序大致對應，那麼它將更適合集羣，例如， billing_date（或issue_date）用於訂單表。 – 2011-05-25 09:51:06

移動聚集索引斷開GUID列，到其他某些列的組合（例如，您最常運行的範圍搜索）

請張貼您的表格結構和索引定義以及問題查詢

在您做出任何更改之前：您需要測量並確定實際瓶頸的位置。

GUID主鍵的一個常見原因是在客戶端層生成這些ID，但是您不提這一點。

此外，您的統計信息是否最新？你是否定期重建索引？

2011-05-25 09:40:52

我們在插入過程中使用Select @OrderID = newid（）。 – Romi24 2011-05-25 09:48:20

@ Romi24：這是不夠的信息。 – 2011-05-25 09:48:48

回答