调大MAXDOP通常不会让大型JOIN变快，反而易引发cxpacket等待、内存不足和负载不均；其生效需满足重编译、无Query Store强制计划、无标量UDF或统计信息准确等前提，OLTP建议MAXDOP≤4并配OPTION(MAXDOP 1/2)，OLAP可试8但须加OPTION(RECOMPILE)。
调大 MAXDOP 通常不会让大型 JOIN 变快，反而容易引发 cxpacket 等等待、内存不足和负载不均——关键不是开多少并行线程，而是让并行真正能跑起来、跑得均衡。
为什么 OPTION (MAXDOP n) 加了也不生效？
语句级提示 OPTION (MAXDOP 2) 看似简单，但实际常被忽略几个前提：
- 它只在查询重编译时生效；若启用了查询存储（Query Store）且强制了旧计划，该提示会被忽略
- 如果查询中存在标量 UDF（如
dbo.fn_get_date()）、GETDATE()直接出现在 JOIN 或 WHERE 条件中，SQL Server 会直接禁用并行 - 统计信息过期或直方图步数太少（
DBCC SHOW_STATISTICS中Steps< 20），优化器可能误判成本，放弃并行 - 执行计划里出现“Serial execution due to operator not supporting parallelism”警告，说明某个运算符（如某些 LOB 操作、CLR 函数）强制串行
OLTP 和 OLAP 场景下 MAXDOP 应该怎么设？
不是“越多越好”，而是按负载特征分层控制：
- OLTP 类 JOIN（如订单查用户+商品，返回几十~几百行）：全局设
sp_configure 'max degree of parallelism', 4，单语句用OPTION (MAXDOP 1)或OPTION (MAXDOP 2)更稳；小表 JOIN（如配置表）直接OPTION (MAXDOP 1)避免调度开销 - OLAP/报表类大扫描 JOIN（如事实表 + 多维表聚合）：可试
OPTION (MAXDOP 8)，但必须配OPTION (RECOMPILE)，否则缓存的低并发计划会复用到高并发场景 - 观察等待类型：大量
cxpacket+ 少量LATCH_EX或PAGEIOLATCH_SH，说明瓶颈不在并行本身，该查 I/O 或锁
JOIN 并行跑不动，除了 MAXDOP 还要看什么？
并行只是表象，底层卡点往往在数据分布和访问路径：
- JOIN 键存在严重倾斜（如 90% 行的
cust_id是 NULL 或 0）：并行线程分配不均，部分线程干等；可用WHERE cust_id IS NOT NULL提前过滤，或加OPTION (HASH JOIN)强制哈希避免排序压力 - 被驱动表（inner side）缺少索引：比如
INNER JOIN customers b ON a.cust_id = b.id，b.id必须有索引，否则走 Clustered Index Scan，放大并行开销 - SELECT 列未被索引覆盖：触发 Key Lookup，串行化瓶颈；建包含列的非聚集索引，如
CREATE INDEX IX_customers_id_name ON customers(id) INCLUDE(name) - 执行计划里出现
Sort Warning或Warning: Memory Grant：说明授予内存不足，需调高min memory per query或拆分查询
如何验证并行是否真起效？
别只看“有没有 Parallelism 运算符”，要盯住三件事：
- 实际线程数：执行后查
sys.dm_exec_query_stats的degree_of_parallelism字段，确认是否等于你设的值 - 线程负载均衡：看执行计划中每个 Parallelism 分支的 Actual Number of Rows 是否接近；若某分支是其他分支的 5 倍以上，就是倾斜
- 资源等待：运行时抓
sys.dm_os_waiting_tasks，重点过滤cxpacket、exchange event、RESOURCE_SEMAPHORE；前者多说明同步开销大，后者多说明内存不够
真正难的不是打开并行，而是让数据、索引、统计信息和查询写法都对齐并行模型——稍一错位，多个线程一起慢，比单线程还糟。
