我一直有一个非常高的CXPACKET等待types，我被告知这是来自并行处理，我应该保持最大并行度=（Nº处理器/ 4），或在我的情况下。
但是CXPACKET仍然很高，达到了32.78％。 有什么build议么？
在将最大并行度降至1之后，您是否清除了等待统计信息？
但是，除了衡量您所做的任何更改的影响之外，确实没有简单的通用经验法则来说明如何configuration此设置。 除了上面的URL之外，我还是推荐Paul Randal读这篇文章。
我还build议重新考虑更多的关注其他顶级等待types – 我经常发现CXPACKET等待是一个红鲱鱼，他们正在发生，因为复杂的查询，并行化成简单的工作，完成迅速和更大， I / O绑定需要很长时间才能完成的工作。 当小而快的工作完成并等待大部分工作完成时，CXPACKET等待显示。
如果您正在调整特定的查询，执行计划应该会显示查询的哪些部分需要很长时间才能完成，然后您可以调整以解决问题。 过时的统计数据或者select不当的指标往往是那里的罪魁祸首。
这实际上并不意味着有一个问题….并行是一件好事，CXPacket等待types正在显示，因为SQL Server必须在不同的工作之间进行同步。
当你切换到maxdop = 1时，那段代码的运行时间比平行时慢吗？ 这是布丁的真正certificate，可以这么说。
有很多矛盾的文章，但是这两个是由SQL人员谁知道他们在说什么！ （好吧，其中一个叛逃到甲骨文！）
http://itknowledgeexchange.techtarget.com/sql-server/cxpacket-isnt-the-cause-it-is-a-symptom/
http://sqlserverpedia.com/blog/sql-server-bloggers/cxpacket-maxdop-and-your-oltp-system/
CXPACKET等待types最有可能不是什么导致你的问题，而是它的后果。
这种等待types意味着工人正在等待其他一些操作完成，然后才能继续。 您应该检查负责CXPACKET的会话，看看究竟是什么等待：
SELECT session_id, wait_type, wait_time, start_time, * FROM SYS.dm_exec_requests WHERE session_id > 50 GO SELECT * FROM sys.dm_os_waiting_tasks AS t WHERE session_id > 50 GO 只有在您诊断出问题的真正原因之后，才应该采取行动来尝试缓解。
在不考虑工作量的情况下盲目设置MAXDOP是一个很大的错误。 它可能不一定会伤害，但这是一个好主意（tm）从一个很好的解释支持默认configuration的变化。 如果你不能解释，不要这样做。
从我迄今在实践中看到的情况来看，高比例的CXPACKET等待表明了大型的并行表扫描。
使用SQL事件探查器来分析在实例上运行的查询：它们很可能需要进行索引调整，或者甚至可能被重写以提高效率。 CXPACKET等待只是（可能的）问题的症状 。