HOLDLOCK 对 UPDLOCK 有什么影响？

Question

我见过许多 HOLDLOCK 提示与 UPDLOCK 结合使用的示例（像这样）。但是 Microsoft 的文档提示使得 HOLDLOCK 看起来应该是多余的，因为 UPDLOCK 已经将锁保留到事务结束。 （另外，HOLDLOCK 似乎只适用于共享锁。）

HOLDLOCK 对查询有何影响（如果有的话）？

Answer 1

它有很大的影响。

更新锁采用行上的更新锁、页上的意图更新以及表/数据库上的共享锁。

这不会阻止其他查询访问表中的数据，因为页面/数据库上的锁纯粹是共享锁。他们只是可能不会通过尝试执行与锁相矛盾的操作来与单个行/页/表发生锁冲突。如果发生这种情况，请求将在当前锁后面排队并等待它可用，然后才能继续。

通过使用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（所有企业）中进行测试 - 全部安装在几乎默认设置上，使用所有默认设置创建测试数据库（仅输入数据库名称）。

Answer 2

根据 MSDN 文档，Andrew 的答案是正确的，但是我针对 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. Make确保您指向表格所在的游戏数据库。

2. 突出显示选项卡 1 中更新语句之前的所有内容并执行。

3. 在选项卡 2 中执行相同操作，您会发现选项卡 2 不会完成并且仍在执行。

4. 现在在选项卡 3 中执行简单的 SELECT 在我的环境中它已完成。

5. 突出显示选项卡 1 中的更新语句并执行它（不要尚未执行提交），您将看到选项卡 2 仍在执行。

6. 继续执行选项卡 1 中的提交...选项卡 2 现在将完成选择...您可以运行其余部分。