SQL不涉及超大查询的并行性

Question

我有一个非常大的查询(大约630行)，它涉及大量嵌套的SELECT语句并从多个视图中提取。我们的SQL服务器将并行性设置为2，阈值为95 (这样设置是因为我们的DBA基于其他应用程序对其进行了优化)。这个查询最近开始用5-10分钟来完成，而通常不到一分钟。在调查原因时，我们注意到它似乎从未触发并行性，总是运行串行，并怀疑这可能与其性能有关。奇怪的是，在实验过程中，我们甚至把阈值降到了5秒的默认值，但它仍然不能并行运行。什么能阻止它？

我们一直在一个当时没有人使用的非生产环境上进行测试，所以这是唯一正在运行的查询。我们的DBA也尝试过清除缓存和计划，甚至回收系统，但没有效果。

更新1:根据评论，我已经验证了统计数据是每晚更新的，但是问题仍然存在。我们实际上是将代码回滚到没有严重性能问题的早期版本，但是将继续测试这段代码，因为它应该比旧代码提高性能，而且实际上在初始测试中也是如此。将在此相应更新。

Answer 1

奇怪的是，在实验过程中，我们甚至把阈值降到了5秒的默认值，但它仍然不能并行运行。什么能阻止它？

优化器不会(或不能)生成并行计划的原因有很多。大致如下：

1. 明显的原因，例如配置设置的最大并行度设置为1，运行在带有MAX_DOP = 1的资源调控器工作负载组下，或只有一个逻辑处理器可供Server使用
2. 并行抑制运算

有许多防止并行性的操作，要么是因为它们在并行计划中没有意义，要么是因为产品只是不支持它们(目前为止)。一些例子(不是详尽无遗的！)迫使整个计划是连续的：

• 修改表变量的内容(读取是可以的)
• 任何T标量函数(反正都是邪恶的)
• 标记为执行数据访问的CLR标量函数(普通函数很好)
• 一些内部函数，包括OBJECT_NAME、ENCYPTBYCERT和IDENT_CURRENT
• 快进游标
• 系统表访问(例如sys.tables)

对使用非内联the标量函数的计算列的表(或视图)的任何引用都将导致串行计划，即使该列在query__中未被引用。

1. 基数估计误差

如果目标查询中没有任何绝对阻止并行性的东西，优化器仍然可以选择一个串行替代方案，如果它的估计成本较低。这可能是由不正确的基数估计引起的。

1. 成本计算模型的局限性

Server使用模型估计查询计划中每个操作符的运行时成本。这种模式可能会不正确地花费一个比并行替代方案更便宜的串行计划。优化器总是选择它考虑的最便宜的选项。

当Server花费并行计划时，它通常会将并行迭代器的CPU成本降低一个等于预期运行时DOP的因子。嵌套循环联接的计划可能是一个特殊的问题，因为内部几乎总是连续运行多个线程。并行图标仍然存在，但它们表明存在DOP独立的串行线程。

这种区别也许是微妙的，但它(a)解释了为什么通常强制串行区域的操作符可以在循环连接的内部“并行”运行；(b)优化器不会通过估计的运行时DOP降低内部的CPU成本。与Hash和Merge Joins相比，这使得嵌套循环在并行性成本方面处于不利地位，并且可以解释为什么优化器可能无法选择并行嵌套循环计划。

1. 优化程序代码路径问题

优化器可能根本无法评估并行计划。如果在琐碎的计划阶段找到了最终计划，就会发生这种情况。如果一个琐碎的计划是可能的，并且由此产生的成本低于配置的并行化成本阈值，则将跳过整个优化阶段，并立即返回一个串行计划。

传递琐碎计划的查询仍然可以提前终止优化(在考虑并行性之前)，或者使用足够好的计划查找消息，或者超时。这两种方法都是启发式的，以防止优化器花费比通过减少估计执行时间(成本)获得的优化时间更长的时间。

测试

对需要并行计划没有支持的方法，但是有一些没有文档的技巧(不适合于生产)。一个是暂时设置优化期间使用的CPU权重要高得多，另一个是设置跟踪标志8649。对于Server 2016 SP1 CU2和更高版本，无文档的查询提示OPTION (USE HINT ('ENABLE_PARALLEL_PLAN_PREFERENCE'))执行与TF 8649相同的功能，但不需要管理权限。

所生成的计划可能不是优化器通常会考虑的计划，但是您可以在仔细测试和检查之后，在生产计划指南中捕获它并使用它。

有关更多信息，请参见Sabin的文章“强制并行查询执行计划和Server中的非参数化操作”。