當UPDLOCK在SQL服務器中發佈時？

最近我經歷了SQL服務器中的提示和鎖定。雖然谷歌關於這個話題，我已經閱讀了一個博客，其中一些查詢已被寫入，我不打包理解。這是當UPDLOCK在SQL服務器中發佈時？

BOL狀態：在讀取表時使用更新鎖而不是共享鎖，並保持鎖直到語句或事務結束。我在翻譯這個時遇到了一些麻煩。這是否意味着更新鎖在執行SELECT語句後被釋放，除非事務中的SELECT語句？

我換句話說，我的假設在以下2種情景中是否正確？

方案1：沒有交易

SELECT something FROM table WITH (UPDLOCK) 

/* update locks released */

方法2：交易

BEGIN TRANSACTION 
SELECT something FROM table WITH (UPDLOCK) 

/* some code, including an UPDATE */ 
COMMIT TRANSACTION 

/* update locks released */

示例場景2（簡稱爲計算器博客）

BEGIN TRAN 

SELECT Id FROM Table1 WITH (UPDLOCK) 
WHERE AlertDate IS NULL; 

UPDATE Table1 SET AlertDate = getutcdate() 
WHERE AlertDate IS NULL; 

COMMIT TRAN

請幫助理解以上查詢。

我的第二個問題是：一旦執行select語句同時完成UPDLOCK得到釋放或沒有？

來源

2017-08-16 saurabh gangrade

實際上，在場景1中，說「沒有事務」並不完全正確 - 您只有'SELECT'語句具有**隱式*事務 - 一旦SELECT語句返回，因此在完成隱式事務 –

您在場景2中的假設是正確的。

要回答你的第二個問題，沒有。更新鎖保留在選定的行上，直到事務結束，或者直到更新語句修改這些行時轉換爲排它鎖。使用SSMS逐個檢查每個陳述以驗證。

BEGIN TRAN 
    -- execute sp_lock in second session - no locks yet 
    SELECT Id FROM Table1 WITH (UPDLOCK) WHERE AlertDate IS NULL; 
    -- execute sp_lock in second session - update locks present 
    UPDATE Table1 SET AlertDate = getutcdate() WHERE AlertDate IS NULL; 
    -- execute sp_lock in second session - update (U) locks are replace by exclusive locks (X) for all row(s) returned by SELECT and modified by the UPDATE (Lock Conversion). 
    -- Update locks (U) continue to be held for any row(s) returned by the SELECT but not modified by the UPDATE 
    -- exclusive locks (X) are also held on all rows not returned by SELECT but modified by UPDATE. Internally, lock conversion still occurs, because UPDATE statements must read and write. 
COMMIT TRAN 

    -- sp_lock in second session - all locks gone.

至於情況1中發生的情況，所有T-SQL語句都存在於隱式事務或顯式事務中。塞納里奧1是含蓄：

BEGIN TRAN 
    SELECT something FROM table WITH (UPDLOCK) 
    -- execute sp_lock in second session - update locks (U) will be present 
    COMMIT TRAN; 
    -- execute sp_lock in second session - update locks are gone.

來源

2017-08-16 05:37:48

時，'UPDLOCK'被釋放 - 感謝你們所有人。任何人想要更新這個問題....歡迎來做 –

@saurabhgangrade：嘗試接受任何有助於幫助的答案..https：//stackoverflow.com/help/someone-answers – TheGameiswar

這是否意味着更新鎖在SELECT語句的執行後釋放，除非SELECT語句在一個事務中？

的鎖將立即釋放該行read..but鎖保持將是U鎖，所以任何並行事務試圖修改此將不得不等待

如果您包裝上面選擇在一個事務中，鎖將只釋放時事務被提交，所以任何並行事務獲取鎖與U鎖不兼容將不得不等待

begin tran 
select * from t1 with (updlock)

爲低於第二個場景

BEGIN TRANSACTION 
SELECT something FROM table WITH (UPDLOCK) 

/* some code, including an UPDATE */ 
COMMIT TRANSACTION

試想一下，如果你的選擇查詢返回100行，都將使用U鎖和想象在同一個事務的更新會影響兩行，兩行會被轉換爲x鎖。所以現在你的查詢將有98個u鎖和2個x鎖，直到事務被提交

我想認爲Updlock爲可重複讀，可添加任何新行，但任何並行事務不能刪除或更新現有行

來源

2017-08-16 06:10:09 TheGameiswar

當UPDLOCK在SQL服務器中發佈時？

回答

相關問題