SQL Server无牺牲品的并行交换事件死锁是否存在问题？

这种无受害者的并行内部死锁在SQL Server 2012 SP2版本中确实是个棘手的已知场景，结合你描述的细节，我来梳理下关键信息和可行的解决方向：

核心现象解读 #

• 无受害者的死锁本质：正常死锁会选择一个线程作为受害者终止来打破循环，但这里SQL Server并没有终止任何线程，而是自动重启了整个查询的执行流程——这就是你看到victim-list为空、应用也没收到死锁错误（1205）的原因，只是查询执行时间会比正常情况明显变长。
• 两类等待类型的意义：
  • e_waitPipeNewRow：并行执行计划里，生产者线程等待将新行写入管道，供消费者线程读取
  • e_waitPipeGetRow：消费者线程等待从管道中获取生产者线程写入的行
    这两类等待本身是并行查询执行的正常同步机制，但在特定执行计划结构或版本bug的触发下，会形成循环等待，进而触发内部死锁。

解决建议 #

1. 优先升级补丁 #

SQL Server 2012 SP2的后续累积更新（CU）中，微软修复了多起类似的并行查询内部死锁问题。建议尽快安装该版本对应的最新累积更新，这是从根源上解决问题的最优方案。

2. 临时缓解方案 #

如果暂时无法升级，可以针对出现问题的查询采取以下措施：

• 给查询添加OPTION (MAXDOP 1)提示，强制禁用并行执行，从根本上避免并行线程间的死锁触发条件
• 若这类问题集中在某个数据库，可临时调整数据库级别的最大并行度设置（需谨慎评估对其他查询的影响）：

  ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 1;
  

3. 优化查询与执行计划 #

• 检查触发死锁的查询文本和执行计划，看是否存在复杂的并行分支（比如嵌套并行、多阶段并行聚合等）
• 通过改写查询、创建合适的覆盖索引或更新统计信息，优化执行计划结构，减少并行执行的需求，或者改变并行执行的逻辑，避开死锁的触发点

4. 持续监控 #

继续通过扩展事件跟踪这类死锁，记录更多上下文信息（如完整查询文本、执行计划XML、系统资源使用率等），这些信息既可以帮助你进一步定位问题，也能在需要时提供给技术支持团队用于排查。

内容的提问来源于stack exchange，提问作者Mark Sinkinson