我正在尝试在 SQL Server Management Studio 中(在单独的查询窗口中)执行以下两个查询。我按照我在此处输入的相同顺序运行它们。
当隔离级别设置为READ COMMITTED
时,它们执行正常,但当它设置为REPEATABLE READS
时,事务被死锁。
你能帮我理解这里死锁的是什么吗?
首先:
begin tran
declare @a int, @b int
set @a = (select col1 from Test where id = 1)
set @b = (select col1 from Test where id = 2)
waitfor delay '00:00:10'
update Test set col1 = @a + @b where id = 1
update Test set col1 = @a - @b where id = 2
commit
第二:
begin tran
update Test set col1 = -1 where id = 1
commit
UPD 答案已经给出,但根据建议我插入了死锁图
最佳答案
在这两种情况下,选择使用共享锁,更新使用排他锁。
在 READ COMMITTED 模式下,共享锁在 select 完成后立即释放。
在 REPEATABLE READS 模式下,select 的共享锁一直保持到事务结束,以确保没有其他 session 可以更改已读取的数据。保证同一事务中的新读取会产生相同的结果,除非数据在当前 session /事务中发生更改
最初我以为,您在两个 session 中都执行了“First”。那么解释就很简单了:两个 session 都获取并获得一个共享锁,然后共享锁阻塞更新所需的独占锁。
第二个 session 仅执行更新的情况稍微复杂一些。一个update staement首先会获取一个update lock (UPDLOCK),用于选择必须更新的行,这可能类似于共享锁,但至少不会被共享锁阻塞。接下来,当数据真正更新时,它尝试将更新锁转换为排他锁,但失败了,因为第一个 session 仍然持有共享锁。现在两个 session 互相阻塞。
关于sql-server - 已提交读与可重复读示例,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38745934/