mar*_*jne 30 t-sql sql-server locking
我已经看到很多HOLDLOCK提示与UPDLOCK结合使用的例子(像这样).但是Microsoft的这些提示的文档使得看起来HOLDLOCK应该是多余的,因为UPDLOCK已经持续锁定直到事务结束.(似乎也说HOLDLOCK只适用于共享锁.)
如果有的话,HOLDLOCK如何影响查询？
And*_*rew 63
它有很大的影响.
Update锁对行进行Update锁定,对页面进行Intent更新,对表/数据库进行共享锁定.
这不会阻止其他查询访问表中的数据,因为页面/数据库上的锁是纯粹的共享锁.他们可能不会通过尝试执行与锁相矛盾的操作来对单个行/页/表进行冲突.如果发生这种情况,请求将在当前锁定后面排队并等待它可以继续运行.
通过使用holdlock,强制查询序列化,独占锁定表直到操作完成.这可以防止任何人读取表,除非使用了nolock提示,允许读取可能脏的内容.
要查看效果,请生成示例表'foo'并在其中放入一些垃圾数据.
begin tran
select * from foo with (updlock)
where tableid = 1
-- notice there is no commit tran
打开另一个窗口并尝试:
select * from foo
行返回,现在提交原始查询事务.重新运行它也改为使用holdlock:
begin tran
select * from foo with (updlock, holdlock)
where tableid = 1
返回到另一个窗口并尝试再次选择数据,查询将不会返回值,因为它被独占锁阻止.在第一个窗口上提交事务,将显示第二个查询的结果,因为它不再被阻止.
最后的测试是使用nolock,使用updlock和holdlock再次运行事务.然后在第二个窗口中运行以下命令:
select * from foo (nolock)
结果将自动返回,因为您已接受脏读的风险(未提交读取).
因此,它被认为会产生很大的影响,因为您强制对该表进行序列化操作,这可能是您想要的(取决于所做的更新),或者会在该表上创建一个非常大的瓶颈.如果每个人都使用长时间运行的事务处理繁忙的表,那么它将导致应用程序中的重大延迟.
与所有SQL功能一样,如果使用正确,它们可能很强大,但错误使用功能/提示可能会导致严重问题.当我必须覆盖引擎时,我更喜欢使用提示作为最后的手段 - 而不是默认方法.
编辑为请求:在SQL 2005,2008,2008R2(所有企业版)中测试 - 全部安装在几乎默认的设置上,使用所有默认值创建的测试数据库(仅输入数据库的名称).
Dar*_*ren 13
安德鲁的答案是正确的,根据MSDN文档,但我测试对2008R2和2012年我没有看到这种行为所以请自己测试
我看到的行为如下:
首先在Play数据库上运行它.
CREATE TABLE [dbo].[foo](
[tableid] [int] IDENTITY(1,1) NOT NULL,
[Col2] [varchar](100) NOT NULL,
CONSTRAINT [PK_foo] PRIMARY KEY CLUSTERED
(
[tableid] ASC
)
)
......然后放几排.
现在将此代码粘贴到两个查询选项卡中(更改选项卡二中的"选项卡一"文本):
begin tran
select * from foo with (UPDLOCK, HOLDLOCK)
where tableid = 1
UPDATE foo SET Col2 = 'tab one'
where tableid = 1
commit tran
把它放在另一个标签3中:
select * from foo
where tableid = 1
确保指向表所在的播放数据库.
突出显示选项卡1中的更新语句之前的所有内容并执行.
在选项卡2中执行相同操作,您会发现选项卡2将无法完成并仍在执行.
现在在我完成的环境中执行选项卡3 中的简单SELECT .
突出显示选项卡1中的更新语句并执行它(不要执行提交),您将看到选项卡2仍处于执行状态.
继续执行选项卡1中的提交... 选项卡2现在将完成选择...您可以运行其余的.