Tom*_*Tom 3 sql-server wait-types
我正在运行这篇文章中的查询：
http://sqlity.net/en/708/why-cxpacket-waits-are-not-your-performance-problem/
查看我的线程在等待类型为 CXPACKET 的挂起查询方面正在等待什么。
但是，对于有问题的 SPID，正在运行的线程显示 NULL 的等待类型，而每个其他线程都处于 SUSPENDED 状态，等待类型为 CXPACKET。
我期待其中一个线程具有除 CXPACKET 之外的某种等待类型，谁能向我解释在这种情况下发生了什么？
谢谢
您看到的是具有 CXPACKET 等待的线程实际上已经完成了它们必须做的任何工作，现在正在等待其他活动线程（等待类型为 NULL 的线程）完成。
布伦特·奥（Brent O）用教室做了一个很好的类比。老师向全班分发一堆不同的纸，让他们在上面找出单词。我们需要考虑的是这样一个事实：1）纸叠的大小可能不同2）不同的学生比其他学生阅读得更快/更慢3）一个学生可能会在第一页上找到该单词一次，而下一个学生可能会在第一页上找到该单词一次在 3000 个页面中查找了 400 次。
当您处理并行性时，您会看到一种自然且预期的行为，某些线程比其他线程完成得更快，并且被迫等待直到其他线程完成，重新收集所有线程并为您提供输出。
http://www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/
对于年轻的 DBA 来说，CXPACKET 总是令人困惑的等待类型，通常会出现一些可预见的错误反应。CXPACKLET 等待类型有多个方面，我已经在 SQL Server文章中的对CXPACKET 等待类型进行故障排除中尝试了将大多数 CXPACKET 高的原因放在表中，但也解释了 CXPACKET 的背景，作为正确的理解SQL Server 中的并行性是理解的关键
因此，对于那些不想详细了解的人，我将在此处发布文章摘要（但我绝对建议阅读文章以获取有关 CXPACKET 等待类型的完整信息）：
不要将 MAXDOP 设置为 1，因为这永远不是解决方案
调查查询和 CXPACKET 历史以了解并确定它是否只发生了一次或两次，
因为它可能只是正常
工作的系统中的异常检查查询使用的表的索引和统计信息，并确保它们是最新的
检查并行成本阈值 (CTFP) 并确保使用的值适合您的系统
检查 CXPACKET 是否带有 LATCH_XX（也可能带有 PAGEIOLATCH_XX 或 SOS_SCHEDULER_YIELD）。如果是这种
情况，则应降低 MAXDOP 值以适合您的硬件检查 CXPACKET 是否伴随着 LCK_M_XX（通常伴随着 IO_COMPLETION 和 ASYNC_IO_COMPLETION）。如果是
这种情况，那么并行性就不是瓶颈。对这些
等待统计信息进行故障排除以找到问题的根本原因和解决方案