更新堆表 - RID 上的死锁

Question

我正在设置一个测试用例来证明某个死锁场景，并且需要对正在发生的事情有所了解。 我有一个堆表，通常称为 HeapTable。该表由 2 个事务模拟更新。

交易 1：

BEGIN TRAN

UPDATE HeapTable
SET FirstName = 'Dylan'
WHERE FirstName = 'Ovidiu';

WAITFOR DELAY '00:00:15';

UPDATE HeapTable
SET FirstName = 'Bob'
WHERE FirstName = 'Thierry';

ROLLBACK TRANSACTION

交易 2：

BEGIN TRAN

UPDATE HeapTable
SET FirstName = 'Pierre'
WHERE FirstName = 'Michael';

ROLLBACK TRAN

我首先触发事务 1，紧随其后的是事务 2。正如预期的那样，事务 1 将要求一些独占锁，以及一些意图独占锁。事务 2 将进入并请求同一 RID 上的更新锁：

spid dbid   ObjId       IndId   Type    Resource     Mode   Status
55    5     711673583   0       RID     1:24336:10   X      GRANT
57    5     711673583   0       RID     1:24336:10   U      WAIT

看到第二个事务要求对同一个 RID 进行更新锁定，我有点惊讶，因为我认为这指向单个记录并且两个更新语句处理不同的数据。我以某种方式期待页面级别的冲突。

当事务 1 的第二次更新启动时，事务 2 将被视为死锁牺牲品，导致事务 2 回滚并完成事务 1。

有人可以解释一下为什么第二个事务需要在同一个 RID 上更新锁，尽管更新了不同的记录？

Answer 1

有人可以解释一下为什么第二个事务需要在同一个 RID 上更新锁，尽管更新了不同的记录？

这可以改写为，当没有索引存在时，Update 语句如何获取需要更新的表上的锁..

SQL在Page上获取一个意向排他锁，然后在读取之前尝试在该页的行上获取U锁，如果匹配到要更新的值，这个锁将被转换为X锁。 .

这种U锁策略是为了确保不会在同一行上使用其他不兼容的锁

请参阅下面由 Kalen Delaney 提供的链接，了解有关相同内容的详细信息

http://sqlblog.com/blogs/kalen_delaney/archive/2009/11/13/update-locks.aspx