SQL Server：在锁定通信缓冲区资源上死锁

这种死锁类型可能是什么原因？（一般不会出现死锁）

锁定通讯缓冲区资源

这是否表明系统内存不足并且缓冲区计数超出限制？

详细错误：

事务（进程ID 59）在锁定通信缓冲区资源上与另一个进程死锁，已被选择为死锁牺牲品。重新运行交易

通常看到的完整消息是：

事务（进程ID 53）被锁定死锁 与另一个进程通信缓冲资源，并已被选为死锁受害者。重新运行事务。

这种锁类型通常在SQL Server已并行执行的死锁查询中看到，有时也称为“查询内并行死锁”。我已经看到一些陈述，这也指出系统资源不足，我认为这可能会涉及到很小的程度。

我注意到的确定它是否是并行死锁的一般准则是，当您拉出XML死锁图（可以在2008年及更高版本的system_health会话中完成）时，您会注意到不同的进程ID显示了相同的代码位。执行堆栈。

同样，查看死锁图的资源列表，并注意侍者事件的类型。它们通常会显示“ e_xxxxxx”，或者类似这样的内容：

<waiter-list>
 <waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>

为了尝试解决该问题，在线和书籍中提供了各种途径。我通常首先查看查询/过程的执行计划，然后重点关注显示并行执行的区域。然后从那里开始尝试首先调整查询，然后在最后的手段可能开始使用查询提示。

您将看到解决这些死锁的最常见查询提示正在实现MAXDOP 1。但是，在此之前，您可能需要检查服务器级别MAXDOP和“成本阈值”设置为什么。成本阈值通常默认情况下设置为5，我想将其设置为35或40作为开始，如果所查询的代码段的成本较低，则可能根本不需要并行运行。我不是很喜欢使用MAXDOP查询提示，但这并不意味着它们没有自己的位置和目的。只是我的观点。