我运行 SQL Server Trace 来跟踪一些死锁问题，我被这个评论击中了头，这Parallel query worker thread was involved in a deadlock是死锁的原因。
Q1：这是否意味着同一个查询正在自己死锁？查询执行计划显示了一些并行情况。
Q2：有哪些可能的方法可以“强制”SQL Server 不使用并行性或至少尽可能避免使用它？
问问题
12820 次
2 回答
8
Q1：没有。这只是意味着死锁涉及到 Exchange 操作员。在客户端，您将收到错误“事务（进程 ID n）在 {thread |通信缓冲区} 资源上与另一个进程死锁，并已被选为死锁受害者。”
这种死锁总是包括两个或更多进程，并且总是包括一个锁资源。
这是此场景的重现。在大多数情况下，拥有正确的索引将解决此问题。
当进程自身发生死锁时（在最新版本中非常罕见），它称为查询内并行死锁，您将收到类似“消息 8650，级别 13，状态 1，第 1 行查询内并行导致您的服务器命令（进程 ID n) 死锁。使用查询提示选项 (maxdop 1) 重新运行查询而不使用查询内并行性。有关详细信息，请参阅此链接。
Q2：请参阅 Denis 提供的链接。
于 2012-12-12T20:34:43.933 回答
3
于 2012-12-12T11:51:36.923 回答