在 SQL Server 中使用 OPTION(MAXDOP 1) 的目的是啥？

Posted 2023-05-08

【中文标题】在 SQL Server 中使用 OPTION(MAXDOP 1) 的目的是啥？

【英文标题】：What is the purpose for using OPTION(MAXDOP 1) in SQL Server?在 SQL Server 中使用 OPTION(MAXDOP 1) 的目的是什么？

【发布时间】：2008-10-02 18:43:41

【问题描述】：

我一直不清楚MAXDOP 的用法。我确实知道它使查询更快，并且它是我可以用于查询优化的最后一项。

但是，我的问题是，何时何地最适合在查询中使用？

【问题讨论】：

您应该包括 SQL Server 的版本和服务包。这可能已在更高版本中修复...

【参考方案1】：

正如 Kaboing 所提到的，MAXDOP(n) 实际上控制着查询处理器中正在使用的 CPU 内核的数量。

在完全空闲的系统上，SQL Server 将尝试尽快将表拉入内存并在内存中将它们连接起来。在您的情况下，最好使用单个 CPU 来执行此操作。这可能与使用 OPTION (FORCE ORDER) 具有相同的效果，后者强制查询优化器使用您指定的连接顺序。在某些情况下，我看到 OPTION (FORCE PLAN) 将查询的执行时间从 26 秒减少到 1 秒。

Books Online 继续说MAXDOP 的可能值是：

0 - 根据当前系统工作负载使用可用 CPU 的实际数量。这是默认值和推荐设置。

1 - 抑制并行计划生成。该操作将串行执行。

2-64 - 将处理器数量限制为指定值。根据当前的工作负载，可以使用更少的处理器。如果指定的值大于可用 CPU 数，则使用实际可用 CPU 数。

我不确定MAXDOP 的最佳用法是什么，但是我猜测一下，如果你有一个有 8 个分区的表，你会想指定MAXDOP(8)，因为我/ O 限制，但我可能是错的。

以下是我找到的一些关于 MAXDOP 的快速链接：

Books Online: Degree of Parallelism

General guidelines to use to configure the MAXDOP option

【参考方案2】：

这是对 SQL Server 中并行性的一般漫谈，可能无法直接回答您的问题。

来自在线图书，关于 MAXDOP：

设置最大处理器数 查询处理器可以用来执行 单个索引语句。更少 处理器可以根据使用 当前系统工作负载。

请参阅Rickie Lee's blog 了解并行性和 CXPACKET 等待类型。这很有趣。

一般来说，在 OLTP 数据库中，我的观点是，如果查询成本如此之高，需要在多个处理器上执行，则需要将查询重写为更高效的方式。

为什么添加 MAXDOP(1) 会得到更好的结果？没有实际的执行计划很难说，但它可能很简单，因为执行计划与没有 OPTION 的情况完全不同，例如使用不同的索引（或更可能）以不同的方式连接，使用 MERGE 或 HASH 连接。

【参考方案3】：

顺便说一句，MAXDOP 显然可以用作解决可能令人讨厌的错误的解决方法：

Returned identity values not always correct

【讨论】：

链接已关闭 - mirror

【参考方案4】：

在 SQL Server 中存在一些输入异常的并行化错误。 OPTION(MAXDOP 1) 会避开它们。

编辑：旧的。我的测试主要是在 SQL 2005 上完成的。其中大多数似乎不再存在，但每隔一段时间，我们就会质疑 SQL 2014 做一些愚蠢的事情的假设，我们回到旧的方式并且它有效。我们从来没有设法证明这不仅仅是在最近的案例中生成的错误计划，因为可以依赖 SQL Server 在新版本中正确使用旧方法。由于所有情况都是 IO 绑定查询 MAXDOP 1 不会受到伤害。

【讨论】：

能否详细说明这些错误？

我无法完全限定这些错误，但特别是一个：当左连接预计匹配很少 % 的行时，将尝试假脱机两个表和循环连接，而不是仅使用书签查找并行化。

@Joshua，你知道这些错误是否仍然与 SQL 2012、14 或 16 版本有关吗？

@HappyTown 我希望这些错误会消失，或者至少已经改变。 SQL Server 的每个主要版本的查询优化器都发生了重大变化。此外，SQL Server 2014 收到了一个新的基数估计器（在 2016 年也得到了显着改进）。称它们为 bug 也不完全公平，因为听起来查询结果并没有被更改——它们可能是优化 bug，但它们不是 bug，因为您的结果会很糟糕。

【参考方案5】：

根据我观察到的性能问题，加上我的两美分。

如果简单的查询被不必要地并行化，它可能会带来比解决问题更多的问题。但是，在将 MAXDOP 作为“膝跳”修复添加到查询之前，需要检查一些服务器设置。

在Jeremiah Peschka - Five SQL Server Settings to Change 中，提到了 MAXDOP 和“并行成本阈值”(CTFP) 作为需要检查的重要设置。

注意：在回复Performance problem after migration from SQL Server 2005 to 2012 时，Paul White 还提到了 max server memory 作为检查设置。一篇值得阅读的好 kb 文章是 Using large amounts of memory can result in an inefficient plan in SQL Server

Jonathan Kehayias - Tuning ‘cost threshold for parallelism’ from the Plan Cache 有助于找出 CTFP 的价值。

Why is cost threshold for parallelism ignored?

Aaron Bertrand - Six reasons you should be nervous about parallelism 讨论了 MAXDOP 是解决方案的某些场景。

Paul White - Forcing a Parallel Query Execution Plan 中提到了并行抑制组件