mar*_*c_s 12 performance sql-server-2008 parallelism query-performance performance-tuning
作为我之前关于对 Sharepoint 站点进行性能故障排除的问题的后续问题，我想知道我是否可以对 CXPACKET 等待做些什么。
我知道下意识的解决方案是通过将 MAXDOP 设置为 1 来关闭所有并行性 - 听起来是个坏主意。但另一个想法是在并行开始之前增加成本阈值。执行计划成本的默认值 5 相当低。
所以我想知道是否已经写了一个查询，可以找到执行计划成本最高的查询（我知道你可以找到那些执行持续时间最长的查询等等 - 但是执行计划成本是否可以在某处检索，也是？），这也会告诉我这样的查询是否已并行执行。
有没有人手头有这样的脚本，或者可以向我指出相关的 DMV、DMF 或其他系统目录视图的方向以找出这一点？
Aar*_*and 11
CXPACKET永远不是原因；它得到了所有的责备，但它总是其他东西的征兆。您需要在行动中捕捉这些查询并弄清楚“其他东西”是什么。它可能因查询而异，并且完全关闭并行性 - 正如您所建议的 - 在大多数情况下是不必要的矫枉过正。但它通常是最少的工作，这就是为什么它是如此普遍的“修复”。
如果您可以获得似乎导致高 CXPACKET 等待的查询的实际计划，请将其加载到SentryOne 计划资源管理器中。这背后通常有一个原因；我们展示了哪些并行操作导致了线程偏斜，并且您可以轻松地将其与关闭的估计值相关联（我们突出显示具有至少某个阈值关闭的估计值的操作）。通常潜在的问题是非常糟糕/过时（或不可用）的统计数据。
不幸的是，您将在 sys.dm_exec_cached_plans 中找到的是估计计划。他们不会告诉您计划在实际使用时是否并行，因为实际计划不是缓存的内容。在某些情况下，您希望看到同一查询的串行和并行计划；这不是 SQL Server 处理可能在运行时并行的并行计划情况的方式。（这里有很多关于这个的信息。）