SQL关联查询未走并行，主因通常是MAXDOP被设为1、cost threshold for parallelism设置不当、Azure SQL中MAXDOP锁死为8，或affinity mask/NUMA限制导致并行能力被隐性压制。
SQL 关联查询没走并行，大概率不是查询写得不对，而是 MAXDOP 配置压根没给它机会——它想并行，但被服务器拦住了。
查当前 MAXDOP 值是否被设为 1
很多生产环境出于“怕出错”心态，把全局 MAXDOP 直接设成 1，等于主动禁用所有并行计划。哪怕你有 32 核 CPU，SELECT a.* FROM t1 a JOIN t2 b ON a.id = b.t1_id 这种典型大表关联也只会单线程跑。
- 用
sp_configure 'max degree of parallelism'查当前值；返回结果中run_value是实际生效值 - 如果值是
1，那所有查询（包括关联）默认都不会生成并行计划，除非显式加OPTION (MAXDOP N)提示 - 注意：即使这里显示
0，也不代表一定能并行——还要看cost threshold for parallelism是否足够低，以及查询预估开销是否 ≥ 该阈值（默认是 5）
为什么关联查询仍串行：开销阈值太低或太高
SQL Server 不是“有多个 CPU 就自动并行”，它会先估算查询开销，再和 cost threshold for parallelism 比较。关联查询若涉及小表、索引覆盖好、预估行数少，开销可能低于阈值，直接跳过并行决策。
- 查当前阈值：
sp_configure 'cost threshold for parallelism' - 默认值
5对 OLTP 类关联（如主键 JOIN）往往偏高——这类查询实际很快，但优化器觉得“不值得并行”，就选了串行计划 - 调低到
2或3后，部分中等规模关联可能开始生成并行计划；但别盲目设成1，会导致大量简单查询浪费线程调度开销 - 这个阈值对并行影响是全局的，改之前建议用
SET STATISTICS XML ON抓几个典型关联查询的执行计划，确认它们当前开销值
Azure SQL 或托管实例上 MAXDOP 被锁死为 8
如果你在 Azure SQL 数据库、Fabric 中的 SQL 数据库或 Azure SQL 托管实例上跑关联查询，MAXDOP 默认就是 8，且无法通过 sp_configure 修改（会报错 “Ad hoc update to system catalogs is not supported”）。
- 这意味着：即使你本地 SQL Server 调成
0或16，云上最多只用 8 个线程做并行 - 某些超大关联（比如多表 JOIN + 大量聚合）在 8 线程下仍可能瓶颈明显，这时得靠改写（如拆分中间结果）、加索引或调整统计信息来降低单线程压力，而不是指望提高 MAXDOP
- 若需临时绕过限制，可用查询级提示：
OPTION (MAXDOP 4)或OPTION (MAXDOP 1)，但不能写MAXDOP 12（会被截断为 8）
容易被忽略的硬性限制：affinity mask 和 NUMA 节点
MAXDOP 不是孤立参数。它受底层 CPU 可见性约束，尤其在虚拟化或容器环境中，常被 silently 限制。
- 检查
sys.dm_os_schedulers中status = 'VISIBLE ONLINE'的记录数，这代表 SQL Server 实际“看到”的逻辑处理器数；如果远小于物理核数，MAXDOP再大也没用 - 若启用了
affinity mask（比如绑定了特定 CPU），则MAXDOP的上限会被限制为该掩码覆盖的 CPU 数量 - 在 NUMA 架构服务器上，跨 NUMA 节点调度线程代价高；SQL Server 会优先在单个 NUMA 节点内分配并行线程，若节点内核数少（如每个 NUMA 只有 4 核），即使全局
MAXDOP=8，实际并行度也可能被压制到 4
真正卡住关联查询并行的，往往不是语法或索引，而是这些隐性配置层的“默认值陷阱”。动 MAXDOP 前，先确认你改的到底是“开关”，还是“墙上画的插座”。
