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