readcommitted隔离级别是否会导致死锁(Sql Server)？

Question

我对死锁的理解是 - 两个进程试图争用相同的资源 - 通常是两个进程试图"写"到同一行数据.如果所有进程都在读取数据 - 而另一个进程正在更新数据,那么资源争用​​情况如何？然而,在我们的数据库中,设置为默认事务级别"ReadCommitted",我们看到了几个死锁异常.ReadComitted definitin - 无法读取已修改(但尚未提交)的数据.这很好 - 但是如果遇到这种"脏读",SQL Server会抛出死锁异常吗？有没有人对这种情况有真实的经验？我找到了一篇博文(由stackoverflow开发人员发布,并没有减少:)声称这可能是真的.

谢谢

Answer 1

ReadCommitted事务隔离级别最初Shared Lock在资源上获取 a ，即在读取行时，但是当我们尝试更新行时，它Exclusive lock在资源上获取 a 。多个用户可以在同一行上拥有共享锁并且不会生效，但是一旦一个用户尝试更新一行它就会在该行上获得一个排他锁，这可能会导致 Adead lock当一个用户由于共享而最初可以看到该记录时锁定该行，但现在当用户尝试更新它时，第一个用户已经对其进行了独占锁定。想象一个场景，User1 和 User2 都有共享锁，当他们尝试更新某些记录时，他们都在其他用户需要提交事务的行上获得排他锁。这将导致死锁。
在死锁的情况下，如果Priority Level is not setSQL Server 将等待一段时间，然后它将回滚RollBack事务cheaper。
编辑
是，如果 User1 仅读取数据而 User2 尝试更新某些数据并且该表上有非聚集索引，则有可能。

1. User1 正在读取 Some Data 并在非聚集索引上获取共享锁以执行查找，然后尝试在包含数据的页面上获取共享锁以返回数据本身。

2. 正在写入/更新的用户 2 首先在包含数据的数据库页面上获得排他锁，然后尝试在索引上获得排他锁以更新索引。

Answer 2

是的，它可能发生。想象一下，您有两个进程，每个进程都有自己的事务。第一次更新 TableA，然后尝试更新 TableB。第二个更新 TableB 然后尝试更新 TableA。如果你不走运，两个进程都会设法完成他们的第一步，然后无限期地等待另一个进程以完成第二步。

顺便说一下，这是避免死锁的最常见方法之一：在更新表的顺序上保持一致。如果两个进程先更新TableA，然后再更新TableB，就不会发生死锁。