我的理解deadlocks是 - 两个进程试图争夺同一资源 - 通常是两个进程试图“写入”同一行数据。
如果一个进程所做的只是读取数据，而另一个进程正在更新数据，那么这怎么会是资源争用呢？然而，在我们的数据库中，它被设置为默认事务级别ReadCommitted，我们看到几个死锁异常。
ReadCommited 定义- 无法读取已修改（但尚未提交）的数据。这很好，但是如果 SQL Server 遇到这种情况，它是否应该抛出死锁异常dirty read正在发生？
有人对这种情况有现实经验吗？我发现一篇博客文章（由 stackoverflow 开发人员撰写，同样如此：）声称这可能是真的。
已提交读事务隔离级别最初获得Shared Lock在资源上，即在读取行时，但是当我们尝试更新该行时，它会获得Exclusive lock关于资源。多个用户可以在同一行上拥有共享锁，这不会产生影响，但是一旦一个用户尝试更新一行，它就会在该行上获得独占锁，这可能会导致 Adead lock当用户最初由于行上的共享锁而可以看到该记录时，但现在当用户尝试更新它时，第一个用户已经拥有了排他锁。想象这样一个场景，用户 1 和用户 2 都有共享锁，当他们尝试更新某些记录时，他们都会在其他用户提交事务所需的行上获得独占锁。这将导致死锁。
如果发生死锁，如果Priority Level is not setSQL Server 会等待一段时间，然后就会RollBack该交易是cheaper回滚。
Edit
是的，如果用户 1 仅读取数据并且用户 2 尝试更新某些数据并且该表上有非聚集索引，则这是可能的。
-
User1 正在读取一些数据并获取非聚集索引上的共享锁以执行查找，然后尝试获取包含数据的页面上的共享锁以返回数据本身。
-
正在写入/更新的用户2首先获取包含数据的数据库页上的排它锁，然后尝试获取索引上的排它锁以更新索引。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
