MySQL 8.0+并行查询仅适用于单表、无JOIN/子查询/GROUP BY、WHERE可下推且走全表或范围扫描的简单聚合；JOIN和子查询使其失效，因并行只加速物理扫描，不处理逻辑复杂度。
MySQL 8.0+ 的并行查询（PARALLEL hint 或 innodb_parallel_read_threads）仅适用于**特定场景下的单表扫描类聚合**，对多表 JOIN、子查询、窗口函数或带复杂 WHERE 条件的报表统计几乎无效。盲目开启或依赖它，反而可能因线程争抢、锁升级或临时表膨胀拖慢整体响应。
哪些统计查询能真正用上并行？
只有满足全部以下条件的 SELECT COUNT(*)、SUM()、AVG() 等简单聚合才可能触发并行：
- 单表查询，无
JOIN、无子查询、无GROUP BY - WHERE 条件能下推到存储引擎层，且走的是全表扫描或范围扫描（非索引回表）
- 表使用 InnoDB，且
innodb_parallel_read_threads > 1（默认为 0，即禁用） - 实际扫描行数远超
innodb_read_ahead_threshold，且数据页在 buffer pool 中未完全预热
例如：SELECT SUM(amount) FROM sales WHERE create_time >= '2025-01-01' —— 若该条件无法走索引、且 sales 表极大，才可能启用并行读；一旦加了 JOIN users ON sales.user_id = users.id，并行立即失效。
为什么 JOIN 和子查询让并行“自动退场”？
MySQL 的并行机制不处理逻辑复杂度，只加速物理扫描。而统计类复杂查询的瓶颈通常不在扫描，而在：
-
JOIN过程中的哈希构建或嵌套循环匹配，这些必须串行协调 - 相关子查询（如
WHERE EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id)）强制逐行求值，无法分片 -
GROUP BY需全局归并聚合结果，中间状态无法安全并行维护 - 临时表（
Using temporary）一旦落盘，I/O 成为新瓶颈，并行线程反而加剧磁盘争用
执行 EXPLAIN FORMAT=JSON 查看 query_block 下的 parallel_table_scan 字段：若为 false 或根本不存在该字段，说明优化器已放弃并行路径。
比并行更有效的三类替代方案
对真实业务中的复杂统计（如按月/地区/品类多维汇总），应优先考虑：
-
物化中间结果：用带索引的临时表或汇总表存高频维度组合，例如
CREATE TEMPORARY TABLE tmp_daily_sales AS SELECT date(create_time), product_id, SUM(amount) FROM sales GROUP BY 1,2，再在此基础上 JOIN 和过滤 -
改写为派生表 + 显式 JOIN：把相关子查询转成
FROM (SELECT ... ) derived，让优化器有机会复用物化结果并选择哈希连接 -
应用层分片聚合：按时间范围（如每天）拆分查询，在代码中并发拉取多个
SELECT SUM(...) FROM sales WHERE day = ?，最后合并——可控、可缓存、不加重 DB 锁压力
真正卡住报表性能的，从来不是“能不能并行扫描”，而是“有没有避免重复计算”和“数据流动路径是否绕远”。一个没索引的 GROUP BY，开 16 个并行线程也救不回来；而一个覆盖索引 + 物化中间表的串行查询，往往比幻想中的并行更快、更稳。
