innodb并行查询需手动配置且严格满足条件：仅普通innodb表全表扫描、无索引可用、无limit/聚合等，配合explain format=tree验证；参数设为会话级，ssd建议4–12，hdd限2–4。
innodb_parallel_read_threads 默认为 0，不开启并行查询——你升级到 MySQL 8.0 后，这个功能**不会自动生效**，必须手动确认场景、显式配置、并用正确方式验证。
EXPLAIN FORMAT=TREE 是唯一可信的并行触发证据
普通 EXPLAIN 或 EXPLAIN FORMAT=JSON 完全不显示并行信息；只有 EXPLAIN FORMAT=TREE 输出中出现 Parallel scan on table_name 才代表真正启用。常见误判包括：
- 看到
"parallel_table_scan": true在 JSON 中，但执行时仍是单线程（优化器最终降级） - 执行计划里有
Using index（覆盖索引），哪怕表很大，也根本不会走并行——因为不涉及物理页读取 - 语句带
LIMIT、ORDER BY、GROUP BY、子查询或窗口函数，优化器直接跳过并行路径 - 表是分区表、临时表、MyISAM 或 Memory 引擎，即使配置了参数也无效
哪些 SELECT 真正可能触发 Parallel scan
必须同时满足以下全部条件，缺一不可：
- 目标表是普通 InnoDB 表（非分区、非临时表）
- 执行计划最外层是全表扫描（
type=ALL），且 WHERE 条件无法使用任何索引（如WHERE status = 'ERROR'，而status列无索引） - 无
COUNT(id)、SUM()、AVG()等聚合下推（COUNT(*)有极小概率触发，但不保证） - 无
LIMIT、DISTINCT、UNION、派生表、CTE - 扫描行数足够大（通常 > 百万行），否则优化器认为并行开销不划算
如何安全设置 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
光看 EXPLAIN FORMAT=TREE 不够，得抓运行时行为：
- 用
EXPLAIN ANALYZE查看真实执行树：搜索输出中是否含"parallel_workers": N和"rows_examined_per_worker"；若N > 1且各 worker 行数接近总扫描量 / N，则并行已触发 - 查
performance_schema.threads：运行查询时执行SELECT THREAD_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%SELECT%'，观察是否出现多个query exec类型线程（非 connect 或 sleep） - 对比关闭并行前后的
Handler_read_rnd_next和Innodb_rows_read：并行下后者应明显快于前者，说明数据读取被分摊
EXPLAIN FORMAT=TREE 显示了 Parallel scan，执行时仍可能因 buffer pool mutex 竞争高、gap lock 存在、或某 worker 遇到锁等待而静默退化为串行——此时你看到的只是“启动了并行”，但实际只有一个线程在干活。
