为什么会出现死锁？

Question

我使用一个由两个简单查询组成的小事务：选择和更新：

SELECT * FROM XYZ WHERE ABC = DEF

和

UPDATE XYZ SET ABC = 123
WHERE ABC = DEF

当事务由两个线程启动时，经常发生这种情况，并且取决于隔离级别发生死锁（RepeatableRead，Serialization）。两个事务都尝试读取和更新完全相同的行。 我想知道为什么会这样。导致死锁的查询顺序是什么？我已经阅读了一些关于锁（共享、独占）以及每个隔离级别的锁持续多长时间，但我仍然不完全理解......

我什至准备了一个简单的测试，它总是会导致死锁。我查看了 SSMS 和 SQL Server Profiler 中的测试结果。我开始第一个查询，然后立即开始第二个。

第一个查询：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
SELECT ...
WAITFOR DELAY '00:00:04'
UPDATE ...
COMMIT

第二次查询：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
SELECT ...
UPDATE ...
COMMIT

现在我无法向您显示详细的日志，但它看起来或多或少像这样（我很可能在某处错过了 Lock:deadlock 等）：

(1) SQL:BatchStarting: First query
(2) SQL:BatchStarting: Second query
(3) Lock:timeout for second query
(4) Lock:timeout for first query
(5) Deadlock graph

如果我对锁有很好的理解，在 (1) 中，第一个查询需要一个共享锁（执行 SELECT），然后进入睡眠状态并保持共享锁直到事务结束。在（2）中，第二个查询也使用共享锁（SELECT）但不能使用排他锁（UPDATE），而同一行上有共享锁，这会导致Lock:timeout。但我无法解释为什么会发生第二次查询超时。可能我不太了解整个过程。谁能给个解释？

我没有注意到使用 ReadCommitted 的死锁，但我担心它们可能会发生。 您推荐什么解决方案？

Answer 1

当两个或多个任务由于每个任务对其他任务试图锁定的资源锁定而永久相互阻塞时，就会发生死锁

http://msdn.microsoft.com/en-us/library/ms177433.aspx

Answer 2

“但我无法解释为什么会发生第二次查询超时。”

因为第一个查询持有共享锁。然后第一个查询中的更新也尝试获取排他锁，这让他睡着了。所以第一个和第二个查询都在休眠等待另一个唤醒 - 这是一个导致超时的死锁:-)

在 mysql 中效果更好 - 立即检测到死锁并回滚其中一个事务（您无需等待超时 :-)）。

此外，在 mysql 中，您可以执行以下操作来防止死锁：

select ... for update

这将在事务开始时放置一个写锁（即排他锁），这样您就可以避免死锁情况！也许你可以在你的数据库引擎中做类似的事情。

Answer 3

对于 MSSQL，有一种机制可以防止死锁。您在这里需要的是 WITH NOLOCK 提示。

在 99.99% 的 SELECT 语句的情况下，它是可用的，不需要将 SELECT 与 UPDATE 捆绑在一起。也不需要将 SELECT 放入事务中。唯一的例外是不允许脏读。

将您的查询更改为此表单将解决您的所有问题：

SELECT ...
FROM yourtable WITH (NOLOCK)
WHERE ...

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE ...
COMMIT

Answer 4

我上次处理这个问题已经很长时间了，但我相信 select 语句会创建一个读锁，它只会阻止数据被更改——因此多个查询可以持有并共享一个读锁在相同的数据上。 shared-read-lock 是为了读取一致性，也就是说，如果你在事务中多次读取同一行，那么读取一致性应该意味着你应该总是得到相同的结果。

更新语句需要排他锁，因此更新语句必须等待读锁被释放。

两个事务都不会释放锁，因此事务失败。

不同的数据库实现有不同的策略来处理这个问题，Sybase 和 MS-SQL 服务器使用超时锁升级（从读到写锁升级）——我相信 Oracle（在某些时候）通过使用回滚日志实现读取一致性，其中 MySQL 有不同的策略。