服务器环境：
编辑：我也应该注意到，max_workers_count目前在4处理器框的默认512
我们正在运行的线程池死锁，我相当肯定与并行相关。 死锁图与Bart Duncan关于Intra-Query并行线程死锁的post中的死锁图几乎相同，在死锁输出中我没有看到锁资源的任何提及，正如他的post的警告部分中提到的那样，相信这是一个平行的事情。
我正在调整看起来与这些有关的查询的过程，但这会花一些时间（阅读“几个星期”）。 在此期间，我想知道是否增加线程池将是明智的或不作为临时解决方法。
那里有任何SQL运动员想帮助一个人出去？
（顺便说一下，因为这个问题，现在去SP3不是一种select）
如果和Bart Duncan的博客文章中的并行性有关，那么增加工作者的数量根本不会影响你的死锁情况。 如果它确实是一个并行的死锁，那么您的快速解决scheme是在您正在调整它的时候对OPTION（MAXDOP n）违规查询进行调整，并将其限制回到死锁停止点。 你可能不需要回到DOP 1，我已经看到DOP 4修复它之前。
另一个要注意的是如果在服务器上启用超线程，禁用它。 SQLOS为SQL Server可用的每个逻辑CPU创build一个用户调度程序。 使用超线程技术，您可以获得8个逻辑CPU，这意味着您有8个用户调度程序。 你的查询可能在DOP 8上运行，当你真的有4个CPU可能导致你的问题。 可以通过计算死锁XML图中的进程节点数来判断这是否是问题的一部分。 如果你有8个进程节点，那么你应该尝试在服务器上禁用超线程，看看是否解决了这个问题。
请参阅联机丛书上有关如何更改它的信息： 最大工作者线程选项 ，也可以参阅Ken Henderson旧博客中关于增加最大工作线程的讨论。 除非绝对必要，否则我会非常谨慎。
希望这可以帮助！