UPDLOCK 在 SQL Server 中何时被释放？

Question

最近我研究了 SQL Server 中的提示和锁。在谷歌搜索这个主题时，我读过一篇博客，其中写了一些我无法理解的查询。在这里

BOL 状态：读表时使用更新锁而不是共享锁，并保持锁直到语句或事务结束。我在翻译这个时遇到一些麻烦。这是否意味着更新锁在执行 SELECT 语句后被释放，除非 SELECT 语句在事务内？

也就是说，我在以下两种情况下的假设是否正确？

场景一：无交易

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 的示例（参考 stackoverflow 博客）

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

是否被释放？

Answer 1

您在场景 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 语句要么存在于隐式事务中，要么存在于显式事务中。 Senario 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.

Answer 2

这是否意味着更新锁在执行 SELECT 语句后被释放，除非 SELECT 语句在事务内？

一旦读取该行，锁就会被释放。.但是锁保持将是

U

锁，因此任何尝试修改此行的并行事务都必须等待

如果将上面的 select 包装在事务中，只有在事务提交时才会释放锁，因此任何获取与

U

锁不兼容的锁的并行事务都必须等待

begin tran
select * from t1 with (updlock)

对于下面的第二种情况

BEGIN TRANSACTION 
SELECT something FROM table WITH (UPDLOCK)

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

想象一下，如果您的 select 查询返回 100 行，所有行都将使用

U

锁，并想象同一事务中的更新影响 2 行，这两行将转换为

x

锁。所以现在您的查询将有 98

u 

锁和 2 个

x

锁，直到事务提交

我想将

Updlock

视为可重复读取，可以添加任何新行，但任何并行事务都无法删除或更新现有行