我在我的测试 SQL Server 2014 上安装了 AdventureWorks2014 数据库。我计划执行以下查询：
SELECT *
FROM Sales.SalesOrderDetail sod
INNER JOIN Production.Product p ON sod.ProductID = p.ProductID
ORDER BY Style
在实际执行它之前，我有以下工作线程的图片：
在执行查询时，我再次检查了工作线程的状态：
如您所见，第二张图片中的总 active_workers_count 高于第一张截图中的。从第二个屏幕截图中，我可以假设查询执行所需的工作线程总数为 1+2+1+2=6。但是，当我查看执行计划中索引扫描运算符的属性时，我看到：
看来我的并行度是 4，这意味着 4 个线程正在并行处理行。
我很困惑，无法确定在查询执行期间运行了多少线程。有人可以向我解释为什么 active_workers_count 与 DOP 不同吗？
要理解这一点，您确实需要查看执行计划。这是我在 DOP 4（在 SQL Server 2014 兼容模式下）在 SQL Server 2017 上的查询得到的结果：
每个并行分支都获得 DOP 线程。因此，乍一看，最多有 12 个工作人员可以同时参与此查询。
但是，哈希匹配连接必须在激活探测（下）输入分支之前消耗整个构建（上）输入分支。所以这里是执行的方式，一般来说：
因此，此查询一次最多使用 8 个并行工作线程。 SQL Server 足够聪明地意识到一次只能激活两个分支（因为哈希匹配的阻塞性质），并且只保留 8 个线程（而不是 12 个）：
请注意，它对分支表示“2” - 这是可以同时执行的分支数。
为了解决您对活动工作人员的屏幕截图，一些线程可能会在其他线程之前完成所有工作（例如，因为它们要处理的行较少）。因此，在查询执行的给定点，您可能只有 6 个线程在运行（在 8 个可能的线程中）。
相关阅读：
并行执行计划——分支和线程
在 SQL Server 中，是每个运算符的并行性，还是其他？
在具有四个处理器的机器上，一次只能运行四个线程。但是，您可以拥有四个以上的线程。他们只是互相等待完成步骤并一次又一次地通过处理器直到完成。因此，在较重的负载期间，您会看到比在较低负载时更高的线程数。但是，同时运行的数量受到服务器上的最大并行度或盒子上的物理数量的限制。