CXPACKET 已经成为所有等待类型中最常见的一种了。我通常会在多CPU系统的前五位等待类型统计中看见。
【1】CXPACKET 基本概念
联机丛书：
当尝试同步查询处理器交换迭代器时出现。如果针对该等待类型的争用成为问题时，可以考虑降低并行度。
【1.1】CXPACKET 解释
当为SQL查询创建一个并行操作时，会有多个线程去执行这个查询。每个查询处理不同的数据集或行集。
因为某些原因，一个或多个线程滞后，而产生了CXPACKET等待状态。
有一个组织/协调（organizer/coordinator）线程(Thread 0)，它需要等待所有线程完成并聚合数据来呈现给客户端。
组织线程必须等待所有线程完成处理才能进行下一步。由于组织线程等待缓慢的线程完成处理所产生的等待，就叫CXPACKET等待。
请注意，并不是所有的CXPACKET等待类型都是不好的事情。你也许会遇某个CXPACKET等待是完全有意义的案例，有时它也是不可避免的。
如果你在任何查询上禁止此种等待，那么查询也许会变慢，因为不能为它执行并行操作。
【1.2】在OLTP上解决CXPACKET的办法——调整并行度
CXPACKET 这个等待可以简单理解成CPU相关的等待，主要发生在并行计划中。由于并行计划需要协同多个task同时工作，那么“协同”分配等等操作的时候出现的就是这个等待。
如果 CXPACKET 在你系统中是最为严重的等待，这时候一般的表现是你的CPU很高。
解决方案：适当调整并行度
一般建议系统如果超过32个CPU 那么设置成8或者4，如果系统中都是特别短小且频繁的语句建议设置成1（取消语句并行，要慎重真的符合你的场景才好）
并行开销的阀值（‘Cost Threshold for Parallelism），主要控制SQL优化器何时选用并行计划，建议默认值，此值设置的越小优化器越容易选择并行计划。
并行度（Max Degree of Parallelism）的设置是针对实例级别的设置（2016中可以对单独数据库设置）
【1.3】Data-warehousing /Reporting server 上的CXPACKET
Data-warehousing /Reporting server: 因为查询执行时间一般较长，建议设置“Maximum degree of Parallelism”（MAXDOP）为0。
这样大多数查询将会利用并行处理，执行时间较长的查询也会受益于多处理器而提高性能。
【1.4】Mixed System (OLTP& OLAP)
这样环境会是一个挑战，必须找到正确的平衡点。我采取了非常简单的方法。
我设置“Maximum degree of Parallelism”（MAXDOP）为2，这样意味着查询仍会使用并行操作但是仅利用2颗CPU。
然而，我把“并行查询阀值”设置为较高的值，这样的话，不是所有的查询都有资格使用并行，除了那些查询成本较高的查询。
在一个即有OLTP查询又有报表服务器的系统上，我发现这样做运行得很好。
在这里我将会设置“‘Cost Threshold for Parallelism’”为25（如图）。你可以选择任何值。但你只能通过在系统上做实验来找到合适的值。
在下面的脚本中，我设置“Max Degree of Parallelism”为2，这样的话，那些具有较高成本的查询(这里是25)，将会在2颗CPU上执行并行查询。
同时，不管服务器有多少颗CPU，查询只会选择两颗CPU来执行。