我有一个报告死锁的错误日志：
事务（进程 ID 55）在锁上死锁 | 与另一个进程通信缓冲区资源，并已被选为死锁牺牲品。重新运行事务。
我正在尝试重现此错误，但我的标准死锁 SQL 代码会产生不同的错误：
事务（进程 ID 54）在锁定资源上与另一个进程死锁，并已被选为死锁牺牲品。重新运行事务。
我想非常清楚，我不是在问什么是死锁。我确实了解基础知识。
我的问题是：lock | communication buffer resources在这种情况下是什么意思？什么是“通信缓冲资源”？有lock |什么意义吗？
我最好的猜测是当并行线程组合它们的结果时使用通信缓冲区。任何人都可以确认或否认这一点吗？
我的最终目标是以某种方式触发第一个错误再次发生。
您的问题与并行性有关，并且该错误“没有意义”，因为错误消息没有反映您的问题，并且不要去更改 maxdope 设置。为了找到错误的原因，您需要使用跟踪标志 1204 ，看看如何使用跟踪标志以及您获得的信息。
当你这样做时，你会得到关于为什么、在哪里以及哪一行代码导致锁定的答案。我想你可以从那时起用谷歌搜索你自己，如果没有，然后发布它，你会得到你需要的答案。
我会将消息解释为锁定资源或通信缓冲区资源的某种组合的死锁。“锁资源”是普通的对象锁，“通信缓冲区资源”是用于合并并行查询结果的交换事件。这些在https://blogs.msdn.microsoft.com/bartd/2008/09/24/todays-annoyingly-unwieldy-term-intra-query-parallel-thread-deadlocks/中进一步描述，其中相关段落是：
“exchangeEvent”资源指示查询计划中存在并行运算符。这个想法是将诸如大型扫描、排序或连接之类的操作的工作分开，以便可以在多个子线程上执行。有“生产者”线程完成繁重的工作并将行集提供给“消费者”。查询内并行需要在这些工作线程之间发出信号：消费者可能必须等待生产者向他们提供更多数据，而生产者可能必须等待消费者完成最后一批数据的处理。与并行性相关的等待在 SQL DMV 中显示为 CXPACKET 或 EXCHANGE 等待类型（请注意，这些等待类型的存在是正常的，只是表明存在并行查询执行 - 就其本身而言，这些等待不会'
我见过的其中一个死锁图包括一组只有一个 SPID 的进程以及一个对象锁和交换事件图。我猜消息“事务（进程 ID 55）在锁上死锁 | 与另一个进程的通信缓冲区资源已被选为死锁受害者。重新运行事务”出现而不是“查询内并行性导致您的服务器命令（进程 ID #51) 死锁。由于对象锁和交换事件的组合，使用查询提示选项 (maxdop 1) 重新运行没有查询内并行性的查询，否则自撰写本文以来，SQL Server 中的消息已更改。
您可以使用 MAXDOP 1 作为查询提示 - 即在一个 cpu 上运行该查询 - 而不会影响服务器的其余部分。
这将避免该查询的错误 - 不会告诉您它失败的原因，但如果您必须让它快速工作，它确实提供了一种解决方法:-)