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

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

谢谢

最佳答案
是的,它可能发生.想象一下,你有两个进程,每个进程都有自己的事务.第一次更新TableA然后尝试更新TableB.第二次更新TableB然后尝试更新TableA.如果你运气不好,两个进程都会设法完成第一步,然后无限期地等待另一个进程,以完成第二步.

顺便说一句,这是避免死锁的最常见方法之一:按照更新表的顺序保持一致.如果两个进程首先更新TableA然后更新TableB,则不会发生死锁.

转载注明原文:readcommitted隔离级别是否会导致死锁(Sql Server)? - 代码日志