如何解决死锁问题？

Question

我已经读过这个死锁问题当数据库表开始累积数千行并且许多用户同时开始在同一个表上工作时,对表的SELECT查询开始产生锁争用和事务死锁.

这个死锁问题是否与TransactNo updlock有关？如果你知道这个问题,请告诉我.提前致谢.

Answer 1

死锁可能由于多种原因而发生,有时对死锁进行故障排除可能更像是一门艺术而非科学.

在简单的SQL事件探查器之外,我用来查找和摆脱死锁的是一个轻量级工具,可以在出现死锁时对其进行图形化描述.当您看到死锁时,您可以深入了解并获取有价值的信息.死锁检测器 - http://www.sqlsolutions.com/products/sql-deadlock-detector

这是一个简单的工具,但对我来说,它确实完成了应该做的事情.有一件事:我第一次使用它时,我不得不等待15分钟才能收集足够的指标以开始显示死锁.

Answer 2

高隔离性的一个常见问题是由于以下情况导致的锁升级死锁；即（其中 X 是任何资源，例如行）

• SPID a 读取 X - 获取读锁
• SPID b 读取 X - 获取读锁
• SPID a 尝试更新 X - 被 b 的读锁阻止，因此必须等待
• SPID b 尝试更新 X - 被 a 的读锁阻止，因此必须等待

僵局！可以通过使用更多锁来避免这种情况：

• SPID a 读取具有(UPDLOCK)指定的 X - 获取独占锁
• SPID b 尝试读取 X - 被 a 的独占锁阻止，因此必须等待
• SPID a 尝试更新 X - 正常
• ...（SPID a 提交/回滚，并在某个时刻释放锁）
• ...（SPID b 做它想做的任何事情）

Answer 3

您没有提供足够的信息来直接回答您的问题。

但是，通过使用“正确”索引来覆盖查询工作负载，可以减少（甚至消除）大多数锁定和阻塞。

由于您安排了定期索引维护工作吗？

如果您有SELECT不需要 100% 准确的（即允许脏读等），那么您可以运行一些SELECTSwith WITH(NOLOCK)，这与 READ UNCOMMITED 的隔离级别相同。请注意：我并不是建议您WITH(NOLOCK)到处放置；仅针对那些不需要 100% 完整数据的 SELECT。