抓取到死锁信息（抓取方式参见https://vip.kingdee.com/article/81399817955699456），

    发现4个节点的等待资源类型为e_waitPipeNewRow，查阅微软官方文档，发现下面信说明： 

Parallel query resource owner:

• exchangeEvent id={Port|Pipe}<hex-address> WaitType=<exchange-wait-type> nodeId=<exchange-node-id>

Exchange-wait-type:

• e_waitNone

• e_waitPipeNewRow

• e_waitPipeGetRow

• e_waitSynchronizeConsumerOpen

• e_waitPortOpen

• e_waitPortClose

• e_waitRange

    说明等待的资源类型是跟并行查询相关。该等待类型表示线程正在等待传递数据包。到这基本上怀疑跟查询走了并行计划相关。检查相关的信息，发现死锁的会话ID都是72

    基于上述内容，我们可以知道，SPID=72的SQL语句使用了4个CPU，但执行时，由于并行执行过程中等待数据包产生了相互等待，而引起死锁。

    通过重新标注的下图，能比较清楚的看到等待资源关系情况

    所有的节点形成了一个等待的闭环，从而引起了死锁。

    所以，星空产品建议将SQL Server的CPU的并行度修改1，如果要修改为0或者大于1时，一定需要做好充分的测试验证。（另外并行查询存在数据排序的结果与预期不一致的BUG）

附：

    并行度设置