sql - 为什么会出现死锁？

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