嵌套查询常无法并行，因优化器基于成本估算、统计信息质量、隐式抑制（如标量函数、TOP、ORDER BY）及兼容级别等因素决定是否生成并行计划；调整服务器MAXDOP无效，应重写为JOIN、更新统计信息或用ENABLE_PARALLEL_PLAN_PREFERENCE提示。
嵌套查询本身不会因为加了 MAXDOP 就自动获得更高并行度——SQL Server 查询优化器是否给它生成并行计划，取决于成本估算、数据量、统计信息质量，以及是否被隐式抑制（比如含标量函数、某些聚合或排序）。
为什么嵌套查询常跑不起来并行计划
嵌套查询（尤其是 WHERE col IN (SELECT ...) 或 EXISTS (SELECT ...) 这类）在执行时，外层往往被当作“驱动循环”，内层子查询可能被物化为嵌套循环连接的一部分。此时：
- 若子查询返回结果集小、且外层行数少，优化器直接估算成本低于串行阈值（默认约 5），跳过并行计划生成
- 子查询中用了
TOP、ORDER BY（无对应索引）、标量 UDF、GETDATE()等非确定性函数，会强制禁用并行 - 数据库兼容级别低于 130（SQL Server 2016），部分嵌套逻辑的并行支持不完整
- 服务器级
max degree of parallelism被设为 1，或查询所在数据库启用了LEGACY_CARDINALITY_ESTIMATION，影响成本模型判断
调整服务器级 MAXDOP 前先确认真实瓶颈
盲目把 sp_configure 'max degree of parallelism' 改成 4 或 8，对嵌套查询几乎没用——它只控制「单个操作符」最多能用几个线程，而嵌套查询的并行机会通常卡在「整个计划是否走并行」这一步。
- 先查当前设置：
SELECT value_in_use FROM sys.configurations WHERE name = 'max degree of parallelism'; - 如果返回是 1，说明所有查询（包括嵌套）都被锁死为串行；但改成 0 或 8 也不等于就能并行——仍要看优化器是否愿意生成并行计划
- 真正该调的是查询级行为：比如把
IN子查询重写为JOIN，或确保子查询可被哈希/合并连接替代，才更可能触发并行分支 - 注意：生产环境改
MAXDOP必须配合RECONFIGURE WITH OVERRIDE，且需sysadmin权限；改完建议观察sys.dm_exec_query_stats中execution_count和total_elapsed_time变化
用查询提示强制启用并行（谨慎！）
当确认子查询逻辑干净（无标量函数、无 TOP、有合适索引），但优化器仍选串行计划时，可用 ENABLE_PARALLEL_PLAN_PREFERENCE 提示——这是 SQL Server 2016+ 引入的明确信号，比老式的 OPTION (RECOMPILE) 更直接。
SELECT *
FROM Orders o
WHERE EXISTS (
SELECT 1
FROM OrderDetails od
WHERE od.OrderID = o.OrderID
AND od.Quantity > 100
)
OPTION (USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));- 这个提示不保证一定并行，但会显著提高优化器选择并行计划的概率
- 不能和
MAXDOP提示混用（如OPTION (MAXDOP 4)），否则后者会覆盖前者效果 - 必须搭配实际可并行的物理操作：比如子查询里
OrderDetails表要有覆盖OrderID和Quantity的索引，否则即使提示也生成不了并行扫描 - 测试时务必用
SET STATISTICS XML ON查看执行计划里是否有Parallelism运算符，而不是只看 CPU 时间下降
最容易被忽略的点：统计信息陈旧 + 分区剪枝失效
嵌套查询能否并行，底层极度依赖统计信息对子查询输出行数的估算。如果 OrderDetails 表统计信息半年没更新，优化器可能把一个本该返回 50 万行的子查询估成 500 行，直接判为“不值得并行”。
- 运行
UPDATE STATISTICS OrderDetails WITH FULLSCAN, NORECOMPUTE;后再测 - 若表已分区，检查子查询谓词是否能触发分区消除（例如
WHERE PartitionKey = @p）；否则即使开了并行，也会扫全分区，反而更慢 - 嵌套层级超过 2 层（如 A 包含 B，B 包含 C）时，优化器成本估算误差放大，此时并行收益常被调度开销抵消——这种场景优先考虑展开或物化中间结果
