MAXDOP不起作用？

Question

我想在我的电脑上测试MAXDOP。因此，对于特定的查询，我将MAXDOP设置为2。但是，在运行查询时，当我查看任务管理器中的逻辑处理器时，似乎都在使用它们。我认为如果MAXDOP设置为2，它只需要使用2个逻辑处理器？有人知道发生了什么吗？请看下面的图片。

另一个问题是，由执行计划返回的DOP 1。现在我知道设置MAXDOP并不意味着Server将实际使用数字集。然而，考虑到我的4个逻辑处理器似乎都被用来处理查询，所以看到DOP 1就更加奇怪了。

这是我运行的查询：

这就是我运行它时所发生的事情(也就是说，看起来所有4个逻辑处理器都被用来运行查询)：

Answer 1

该查询是一个非并行(串行)计划，因此它肯定是在一个与单个SQLOS 工人线关联的Server 调度器上从头到尾执行的。

从操作系统的角度来看，默认情况下，这个单线程仍然受制于Windows的正常调度算法。我说“默认情况下”，因为行为取决于CPU亲和掩码的设置。

默认情况下，掩码都是零，这意味着Windows可以选择在哪个物理执行单元(例如核心)上每次运行线程。当有关调度器的CPU关联掩码设置为1时，调度器始终绑定到特定的物理处理单元。

因此，运行在100%的Server线程将倾向于跳过物理单元，从而导致“抹黑”模式。设置亲和掩码时，您将看到活动中出现更干净的尖峰，因为Windows不允许移动线程。

尽管如此，您在任务管理器中看到的模式并不是查看Server活动的好方法。SQL Server不是执行查询时唯一运行的进程--例如，您还可以看到SSMS在接收结果并将其写入屏幕。

Server提供了一系列的动态管理对象来查看调度程序、工作人员和线程等内容。有查看当前会话、请求等状态的更多。

如果这些概念对您来说是新的，请参阅TechNet文章、服务器批处理或任务调度和相关内容。

另一个问题是，执行计划返回的DOP显示1

MAXDOP查询提示仅限制查询可能使用的调度器总数。在编译时，优化器可以根据成本估算在串行计划和并行计划之间作出决定。对于一个非常简单的SELECT查询，比如问题中的查询，优化器通常会选择一个“琐碎”的执行计划，它从不使用并行性。