MySQL 8.0 并行查询仅对InnoDB无索引全表扫描或范围扫描生效，需显式配置innodb_parallel_read_threads>0、用EXPLAIN FORMAT=TREE验证，不适用于索引查找、聚合、LIMIT等场景。
MySQL 8.0 并行查询不是“自动开箱即用”的功能
它只对特定执行路径生效，且默认关闭。你执行 EXPLAIN ANALYZE 看到的并行扫描（Parallel scan）字样，并不意味着当前查询一定走并行——它取决于表结构、访问方式、优化器决策和关键配置项是否就位。
常见误判现象：EXPLAIN FORMAT=JSON 中出现 "parallel_table_scan": true，但实际执行时仍单线程跑完；或 SHOW VARIABLES LIKE 'innodb_parallel_read_threads' 返回 4，却对 WHERE id = ? 这类索引查找毫无作用。
-
innodb_parallel_read_threads仅影响 InnoDB 的**全表扫描**和**范围扫描**（如WHERE created_at > '2025-01-01'），对等值索引查找（type: const/ref）完全无效 - 并行扫描必须满足：查询未使用覆盖索引、未命中唯一索引、未被优化器判定为“太小而无需并行”（通常行数
- 并行任务由存储引擎层（InnoDB）发起，执行器（server layer）只负责合并结果；这意味着
JOIN或ORDER BY后续阶段仍串行执行，瓶颈可能转移
如何确认并行扫描真正在工作
光看 EXPLAIN 不够，得抓实际执行时的线程行为和耗时分布。MySQL 8.0 提供了两个不可替代的验证手段：
- 用
EXPLAIN ANALYZE查看真实执行树：搜索输出中是否含"parallel_workers": N和"rows_examined_per_worker"字段；若N > 1且各 worker 行数接近总扫描量 / N，则并行已触发 - 查 performance_schema：运行查询同时执行
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增长速率：并行下后者应明显快于前者，说明数据读取被分摊
并行扫描在执行器中的实际合并逻辑很轻量
执行器本身不参与数据分片或调度，它只做三件事：接收多个 row_iterator、轮询拉取、归并结果集。这意味着：
- 没有全局排序或去重——如果原始查询带
ORDER BY或DISTINCT，这些操作仍在主线程完成，且可能因并行打乱顺序而额外消耗内存 - 聚合函数（
COUNT(),SUM()）会被下推到每个 worker，执行器只做最终加总；但GROUP BY的分组键若分布不均，会导致 worker 负载倾斜（比如某 status 占 90% 数据） - 执行器不会等待所有 worker 完成才开始返回结果——只要第一个 worker 有数据，就可流式输出；这对
LIMIT查询友好，但也会让EXPLAIN ANALYZE显示的“first row time”失真
容易被忽略的硬性限制和副作用
并行不是银弹，尤其在线上 OLTP 场景中，盲目开启反而拖垮整体吞吐：
- 每个并行 worker 都会独立申请
sort_buffer_size和read_buffer_size，线程数翻倍 ≈ 内存占用翻倍；若设置innodb_parallel_read_threads = 8但sort_buffer_size = 4M，仅此一项就多占 28MB 内存 - 并行扫描会绕过部分锁机制（如 record lock），在高并发更新场景下可能读到“半提交”状态的页，虽不违反 MVCC，但和预期一致性有偏差
- 对 SSD 友好，对 HDD 可能变慢：多个 worker 同时随机寻道，加剧磁盘争用；实测中
innodb_parallel_read_threads > 2在 SATA SSD 上收益明显，但在 NVMe 上常在 4–6 达到拐点 - 备份工具（如 mydumper）、监控代理（如 pt-query-digest）可能无法正确解析并行查询的慢日志格式，导致统计失真
真正起效的调优点不在“开多少线程”，而在让扫描本身值得并行：删掉无用字段、避免 SELECT *、确保 WHERE 条件无法走索引——否则优化器根本不会考虑并行路径。
