并行执行不能解决JOIN性能根本问题，需优先优化索引、统计信息和查询字段；SQL Server的Hash Match警告、MySQL Parallel Query的苛刻条件、PostgreSQL并行扫描对JOIN无效，均说明并行是锦上添花而非雪中送炭。
并行执行在SQL Server中触发Hash Match警告
SQL Server的并行JOIN（尤其是Hash Join）不是“开越多线程越快”，而是容易因资源争抢、内存不足或数据倾斜导致退化。当你看到执行计划里Hash Match节点带红色警告，或出现Warning: Hash bailout，基本说明并行没帮上忙，反而拖慢了。
- 并行线程间需要同步哈希表，当数据分布不均（比如90%订单属于3个VIP用户），部分线程负载过重，其他线程空等
-
max degree of parallelism设得过高（如设为0或8），但物理CPU只有4核、内存仅16GB，线程上下文切换开销盖过了计算收益 - Hash表无法完全放入内存，被迫写入tempdb——执行计划里出现
Spill Level: 1+或LOB Logical Reads飙升，IO成为瓶颈
MySQL 8.0+的并行查询（Parallel Query）实际生效条件极苛刻
MySQL官方文档明确说明：Parallel Query仅对SELECT语句中的range扫描生效，且要求表引擎为InnoDB、主键为整型、无ORDER BY/LIMIT、查询列不能含大字段（VARCHAR(MAX)、TEXT）。绝大多数JOIN场景根本不走并行路径。
- 你写了
SELECT /*+ PARALLEL(4) */ ... FROM t1 JOIN t2 ON ...，但EXPLAIN里Extra仍显示Using where，没有Using parallel——说明优化器直接忽略提示 - JOIN涉及
datetime范围过滤（如WHERE created_at > '2024-01-01'），哪怕加了索引，只要不是主键等值扫描，Parallel Query就不可用 - 复合索引
(user_id, status)上只用status = 'active'，缺失最左前缀，优化器连单线程索引都弃用，更别说并行
PostgreSQL的parallel_seq_scan对JOIN几乎无效
PostgreSQL的并行能力集中在顺序扫描（parallel_seq_scan），但JOIN的性能瓶颈从来不在“扫得快”，而在“匹配得准”。即使启用了max_parallel_workers_per_gather = 4，只要JOIN字段没索引，它只是并行地做全表扫描+嵌套循环，总耗时可能比单线程还高——因为多线程争抢shared_buffers和CPU缓存。
- EXPLAIN ANALYZE输出里
Workers Planned: 3但Actual Total Time翻倍，说明worker间通信和结果合并成本超过收益 -
JOIN右侧表（被驱动表）若没索引，每个worker都要独立扫描整张表找匹配行，O(N×M)复杂度被放大N倍 - 使用
pg_stat_statements查到total_time上升、calls不变，但blk_read_time占比超70%，就是并行IO拖垮了整体
真正该优先调的不是并行度，是JOIN本身的可优化性
并行是最后一步“锦上添花”，不是“雪中送炭”。当你的JOIN已经慢到要靠并行救场时，大概率前面三个环节早崩了：索引缺失、统计信息过期、中间结果集膨胀。强行开并行，就像给漏油的发动机猛踩油门。
- 先跑
EXPLAIN (ANALYZE, BUFFERS)（PG）或SET STATISTICS IO ON（SQL Server），确认logical reads是否动辄百万级——如果是，加索引比调并行管用10倍 - 检查
rows预估是否严重失准（比如预估100行，实际扫描50万行），运行ANALYZE TABLE或UPDATE STATISTICS比改cost_threshold_for_parallelism更直接 - 把
SELECT *改成只取必要字段，尤其避开JSON、XML、VARCHAR(MAX)——这些字段会强制关闭并行，且让每个worker加载更多LOB页
并行开关背后没有魔法，只有资源与算法的硬约束。它解决不了索引失效、数据倾斜、估算错误这些根子上的问题。
