服务器环境：
- Windows 2003 标准 R2 x64 SP2
- SQL 2005 企业版 64 位 SP2
- HP ProLiant BL460c G1，Xeon E5440 2.83 Ghz 处理器（四核）
- 8 GB 内存
编辑：我还应该注意到，对于 4 处理器盒，max_workers_count 目前为默认值 512
我们遇到了线程池死锁，我相当确定这与并行性有关。死锁图与 Bart Duncan 的帖子中的死锁图几乎相同查询内并行线程死锁，并且我没有看到死锁输出中任何关于锁资源的提及，正如他在帖子的注意事项部分所提到的，这让我相信这是一个并行性的事情。
我正在调整与这些查询相关的查询，但这需要一点时间（读作“几周”）。与此同时，我想知道增加线程池是否明智，或者作为临时解决方法。
有没有 SQL Jocks 愿意帮助别人？
（顺便说一句 - 现在无法升级到 SP3，因为这个问题）
答案1
如果死锁与并行性有关，那么增加工作线程数量根本不会影响死锁情况，正如 Bart Duncan 的博客文章中所述。如果确实存在并行死锁，那么快速修复方法是在调整有问题的查询时对其进行 OPTION(MAXDOP n)，并将其限制回死锁停止的点。您可能不一定需要返回到 DOP 1，我之前见过 DOP 4 修复了这个问题。
另一件要查看的事情是服务器上是否启用了超线程，请禁用它。SQLOS 为 SQL Server 可用的每个逻辑 CPU 创建一个用户调度程序。使用超线程，您将获得 8 个逻辑 CPU，这意味着您有 8 个用户调度程序。您的查询可能以 DOP 8 运行，而您实际上只有 4 个 CPU，这可能会导致您的问题。您可以通过计算死锁 XML 图中进程节点的数量来判断这是否是问题的一部分。如果您有 8 个进程节点，那么您应该尝试在服务器上禁用超线程，看看这是否能解决问题。
答案2
请参阅联机丛书上的此条目以了解如何更改它：最大工作线程选项并参见有关增加最大工作线程数的讨论Ken Henderson 的旧博客。除非绝对必要，否则我会非常谨慎地做这件事。
希望这可以帮助！