2012-05-24 91 views
1

我有一個非常基本的表稱爲標題下面,SQL死鎖INSERT,UPDATE statments存儲過程

TitleID - auto identity and PK 
UserID - reference key to User table 
Title - varchar 
IsPrimary - bit 

只有一個指數,這是TitleID

現在我插入記錄在PK聚集索引該表格通過在READCOMMITTED事務存儲過程,

此存儲的過程中插入該記錄與值isPrimary = 1的表和更新所有其他標題爲0

INSERT INTO Titles(...) 
    VALUES (...) 

UPDATE T 
SET IsPrimary = 0 
FROM Titles T 
WHERE T.UserID = @UserID AND T.JobTitle != @Title 

當我在多用戶場景中測試此問題時,我遇到了死鎖問題。如果我從存儲過程中刪除UPDATE命令,然後一切工作完全正常...

我試圖在查詢列上創建非聚集索引,並嘗試WITH(ROWLOCK)提示更新語句,但似乎沒有任何工作。

當我運行SQL語句和查看估計執行計劃,我可以看到這兩個更新聚集索引,我想這是它多用戶場景中失敗......

我認爲這是相當簡單的場景很多人都應該在高交易系統中實施這種行爲,但我無法找到任何有關如何解決這個問題的方法,並且我們將不勝感激。

謝謝。

回答

0

您的死鎖可能是在索引資源上。

在執行計劃中查找書籤/密鑰查找並創建一個覆蓋這些字段的非聚集索引 - 這樣UPDATE的「讀取」數據不會與INSERT的「寫入」衝突。

+0

Kev謝謝你的回覆。我也認爲死鎖僅僅在索引資源上,但是對於實際的更新語句不是用於過濾器/查找......因爲它是聚簇索引,當表中有任何變化時它需要更新(希望我的理解是正確的)並且在相同另一次插入可能會發生,這將觸發死鎖。你明白我的意思嗎?如果我正確地理解了你關於創建非集羣索引,正如我在初始文章中提到的那樣,我在update語句的where子句中使用的列上創建了非索引集羣,但它沒有區別..其他建議? – user1414962

+0

沒有插入(不管有多少併發)不應該發生死鎖 - 最壞的情況是阻塞,但不會造成死鎖。您確實需要檢查死鎖圖的輸出以找出鎖定的確切資源 - 從這裏開始很困難:) –