0

最近我经历了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得到释放或没有?

+2

实际上,在场景1中,说“没有事务”并不完全正确 - 您只有'SELECT'语句具有**隐式*事务 - 一旦SELECT语句返回,因此在完成隐式事务 –

回答

0

您在场景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. 
+0

时,'UPDLOCK'被释放 - 感谢你们所有人。任何人想要更新这个问题....欢迎来做 –

+0

@saurabhgangrade:尝试接受任何有助于帮助的答案..https://stackoverflow.com/help/someone-answers – TheGameiswar

0

这是否意味着更新锁在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为可重复读,可添加任何新行,但任何并行事务不能删除或更新现有行