当 UPDLOCK 在 SQL Server 中发布？答案

【问题标题】：When UPDLOCK get released in SQL server?当 UPDLOCK 在 SQL Server 中发布？
【发布时间】：2017-08-16 03:48:34
【问题描述】：

最近我在 SQL Server 中使用了提示和锁。虽然谷歌关于这个话题我读过一篇博客，其中写了一些我无法理解的查询。这里是

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

换句话说，我在以下 2 个场景中的假设是否正确？

场景一：没有交易

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 会被释放吗？

【问题讨论】：

实际上，在场景 1 中，说“无事务”并不完全正确 - 您确实有一个隐式事务，只是为了 @ 987654325@ 语句 - 一旦 SELECT 返回就完成，因此 UPDLOCK 被释放 - 在隐式事务完成后

标签： sql-server transactions locking database-administration query-hints

【解决方案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.

【讨论】：

感谢大家。任何想更新这个问题的人....欢迎做
@saurabhgangrade：尝试接受任何有帮助的答案..stackoverflow.com/help/someone-answers

【解决方案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 个 xlocks 直到事务提交

我想将Updlock 视为可重复读取，可以添加任何新行，但任何并行事务都不能删除或更新现有行

【讨论】：