MySQL 8.0并行查询仅在满足全部条件的全表扫描场景生效：普通InnoDB大表、无索引可用、无LIMIT/GROUP BY/子查询等、执行计划最外层为扫描，且须用EXPLAIN FORMAT=TREE验证显示“Parallel scan”才真正启用。
MySQL 8.0 的并行查询不是“设了就快”，它只在极少数全表扫描场景下生效，且必须用 EXPLAIN FORMAT=TREE 验证，否则你根本不知道它有没有启动。
为什么 SET innodb_parallel_read_threads=4 后没效果？
因为参数只是必要条件，不是充分条件。常见失效原因包括：
-
EXPLAIN或EXPLAIN FORMAT=JSON完全不显示并行信息——只有EXPLAIN FORMAT=TREE的输出里出现Parallel scan on table_name才算真正启用 - 语句带
LIMIT、ORDER BY、GROUP BY、DISTINCT、子查询或窗口函数，优化器会直接跳过并行路径 - WHERE 条件能走索引（哪怕只是部分命中），就会退回到索引查找，绕过并行扫描机制
- 表是 MyISAM、Memory、分区表，或 InnoDB 表但事务隔离级别为
REPEATABLE READ且存在 gap lock，也可能静默降级
哪些 SELECT 真的能触发 Parallel scan？
必须同时满足以下全部条件：
- 目标表是普通 InnoDB 表（非分区、非临时表）
- 执行计划最外层是全表扫描（即
WHERE条件无法使用任何索引，或压根没写WHERE） - 无聚合函数（
COUNT(*)可能触发，但COUNT(id)、SUM()在多数版本中不保证并行） - 无
LIMIT、ORDER BY、GROUP BY、DISTINCT、UNION、派生表等上层改写逻辑 - 查询涉及数据量足够大（通常 > 百万行），否则优化器认为并行开销不划算
例如：SELECT * FROM huge_log_table WHERE level = 'ERROR' —— 若 level 列无索引，才可能并行；若已有索引，则一定不并行。
怎么安全设置 innodb_parallel_read_threads 值？
这个参数是会话级的，值设太高反而拖慢，关键看硬件瓶颈：
- SSD 场景：从
SET SESSION innodb_parallel_read_threads = 4开始测试，逐步加到 CPU 核心数的 1–1.5 倍（如 16 核设 8–12）；超过 32 很少有收益，实测 64 线程比 32 还慢 - HDD 场景：设 2–4 就顶天了，再多线程争抢磁头寻道，延迟反升
- 生产环境想长期生效，必须写进
my.cnf的[mysqld]段：innodb_parallel_read_threads = 4；SET GLOBAL不影响已存在的连接 - 注意：该参数控制的是“每个满足条件的查询最多可用的后台线程数”，不是全局并发池
最容易被忽略的硬性限制
即使 EXPLAIN FORMAT=TREE 显示了 Parallel scan，仍可能在执行时被静默降级：
- 另一会话对同一张表有未提交的写事务（哪怕只是
INSERT），InnoDB 为避免读取未提交数据，会强制切回单线程 - 当前事务开启
gap lock（比如REPEATABLE READ下执行了范围UPDATE），并行扫描会被禁用以保证 MVCC 可见性一致性 - 扫描过程中 buffer pool 命中率极高（比如反复查同一张热表），I/O 成本下降，并行收益消失，引擎可能动态放弃并行
所以别只信 EXPLAIN 输出，一定要用真实大表 + 真实负载跑一次 SELECT，再结合 SHOW PROFILE 或 performance_schema 查看实际线程行为。
