我的 CXPACKET 等待类型一直很高，有人告诉我，它源于并行处理，我应该保持最大并行度 = (处理器数量 / 4)，或者在我的情况下为 1。
但 CXPACKET 等待时间仍然很高，占所有等待时间的 32.78%。有什么建议吗？
答案1
将最大并行度降低到 1 后，您是否清除了等待统计数据？
但实际上，除了衡量您所做的任何更改的影响之外，没有关于如何配置此设置的简单、通用的经验法则。除了上述 URL 之外，我建议您阅读这保罗·兰德尔 (Paul Randal) 的帖子。
我还建议重新考虑更多地关注其他主要等待类型——我经常发现 CXPACKET 等待是一种转移注意力的手段，它们之所以发生是因为复杂的查询被并行化为简单的工作，这些工作可以快速完成，而较大的 I/O 密集型工作需要很长时间才能完成。当小而快的工作完成并等待较大的工作完成时，就会出现 CXPACKET 等待。
如果您正在考虑调优特定查询，执行计划应该会显示查询的哪些部分需要很长时间才能完成，然后您就可以进行调优来解决问题。过时的统计数据或选择不当的索引通常是罪魁祸首。
答案2
这实际上并不意味着存在问题....并行性是一件好事，而 CXPacket 等待类型只是因为 SQL Server 必须在不同的工作之间进行同步而显示。
当你切换到maxdop = 1时，这段代码的运行时间是否比并行时慢？可以说，这是真正的验证。
网上有很多互相矛盾的文章，但这两篇文章是由 SQL 专家撰写的，他们知道自己在说什么！（好吧，其中一人叛逃到了 Oracle！）
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/
答案3
CXPACKET 等待类型很可能不是导致问题的原因，而是问题的结果。
这种等待类型意味着工作进程正在等待其他操作完成才能继续。您应该检查负责 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
只有在诊断出问题的真正原因后，您才应该采取措施尝试缓解问题。
答案4
在我看来，盲目地设置MAXDOP实例而不考虑工作量是一个很大的错误。虽然这不一定会带来伤害，但用一个非常好的解释来支持对默认配置的更改是一个好主意 (tm)。如果你无法解释，就不要这么做。
从我迄今为止的实践中看到的情况来看，CXPACKET 等待百分比高表明存在大量并行表扫描。
使用 SQL Profiler 分析实例上运行的查询：它们很可能需要进行索引调整，甚至可能需要重写以提高效率。CXPACKET 等待仅仅是症状可能出现的问题。