阅读 SQL 死锁图

Question

有人可以帮助我阅读/理解这个死锁图吗？

我不明白为什么进程75正在请求一个他已经拥有锁的对象的锁？

- Jacques

---

你能发送“show innoDB status”响应吗？这样会更详细，它应该包含最后一个死锁。 - varela

@varela - 这是SQL Server。jaques，你用的是哪个版本？看起来像是并行问题。 - Martin Smith

@Martin Smith。SQL Server 2008 - Jacques

@jaques - 如果您在问题中发布相关的表结构，包括索引以及死锁图形的XML版本，则很可能可以获得更具体的答案。 - Martin Smith

@Martin。这是一款商业产品，我不感觉透露内部细节很舒服。 - Jacques

Answer 1

根据我找到的一篇博客文章，存在一个“Exchange Event”可能表明您的问题源于查询中的并行性。这篇文章详细介绍了这个问题，但结论是：

解决办法 #1：添加索引或优化查询以消除对并行性的需求。在大多数情况下，查询中使用并行性表示您有一个非常大的扫描、排序或连接，而不受适当索引的支持。如果调整查询，通常会发现您会得到更快、更有效的计划，不使用并行性，因此不会出现这种类型的问题。当然，在某些查询（特别是DSS/OLAP类型的查询）中，可能难以消除所有大型扫描。

解决办法 #2：在查询的末尾使用“OPTION(MAXDOP 1)”查询提示强制执行单线程操作。如果无法修改查询，则可以将提示应用于具有计划指南的任何查询。

您可以尝试这个方法，看看是否有所改善。

- Justin

---

谢谢，我成功地识别和改进了一个运行缓慢的查询，并且此后没有锁定。不确定如何在将来防止这种情况？为什么SQL服务器会尝试变得聪明，如果有可能会陷入死锁的情况呢？（例如，为什么要使用并行处理？） - Jacques

所引用的链接专注于“纯”交换事件内查询死锁，其中只有一个SPID（因此是“内部查询”）。问题的死锁图包括一个交换事件和涉及2个查询（另一个SPID）的更传统的死锁。我已经阅读过孤立的死锁交换事件可以自行修复（因为它们可能是由于内部错误），因此重点应放在其他共享对象上 - 在这种情况下是页面锁定。 - crokusek