mysql 8.0 并行查询仅对满足全部条件的innodb无索引全表扫描生效，需显式设置innodb_parallel_read_threads>0且用explain format=tree验证显示“parallel scan”才启用，不适用于聚合、limit、索引查找等常见场景。
MySQL 8.0 的“并行查询”不是你加个 hint 就能自动拆成多线程跑的通用加速器——它只在极少数特定场景下由优化器主动启用，且默认关闭。盲目期待并行，反而会忽略真正拖慢查询的底层问题。
哪些查询 MySQL 8.0 真正会并行执行？
MySQL 8.0 的并行能力集中在 InnoDB 层的物理扫描阶段，仅对以下三类操作可能触发（需满足全部前提）：
- 全表扫描（
type=ALL）或大范围索引扫描（type=range），且表数据量远超innodb_buffer_pool_size缓存能力 - 聚合类操作：含
COUNT(*)、SUM()、AVG()等，且无 GROUP BY 或 GROUP BY 字段无索引 - 某些大表 JOIN 的驱动表扫描（如
ref或eq_ref失效退化为扫描时）
注意：UNION ALL、子查询、ORDER BY、LIMIT、带函数的 WHERE 条件——这些统统不会触发并行。EXPLAIN 输出里看不到 Using parallel scan 或类似提示，基本就等于没并行。
innodb_parallel_read_threads 是什么，该不该调？
这个变量控制单次并行读取最多启用的线程数（默认 4，最大 64），但它不等于“并行查询开关”。它的生效有硬约束：
- 仅对 InnoDB 表的物理页读取起作用，不改变 SQL 逻辑计划
- 若查询走的是覆盖索引（
Extra: Using index），根本不会触发磁盘/缓冲池页读，此参数无效 - 若系统已满载（CPU > 90%、buffer pool mutex 竞争高），强行开多线程反而加剧锁争用
实操建议：先用 SHOW PROFILE FOR QUERY N 或 performance_schema.events_statements_summary_by_digest 确认瓶颈在 handler_read_rnd_next（随机读页）阶段，再考虑从 4 逐步试到 8；超过 16 基本无收益，还可能引发 InnoDB: Warning: parallel read threads exceed available CPU 日志。
为什么 EXPLAIN 看不到并行，但实际执行变快了？
因为并行发生在存储引擎内部调度层，优化器生成的仍是串行逻辑计划。你看到的 EXPLAIN 输出是“怎么算”，不是“几个核一起算”。真正影响耗时的是最慢那个 I/O 路径：
- 如果某张大表没索引，
innodb_parallel_read_threads再高也救不了——它只是让全表扫描快一点，但仍是全扫 - 如果多个子查询共用同一张宽表且都走
idx_status_created，高并发下索引 B+ 树页争用（dict_index_wait_for_x_lock）会让并行退化为排队 - 临时表写磁盘（
Extra: Using temporary; Using filesort）时，并行读毫无意义——瓶颈已切到磁盘写和排序缓冲区
所以比调参更关键的是：用 EXPLAIN FORMAT=TREE 看是否每个分支都 rows 合理、key 命中、Extra 没 Using temporary；否则并行只是给慢查询加速跑向失败。
真正值得优先做的三件事
与其纠结并行，不如立刻检查：
- 所有
WHERE条件字段是否都有索引？特别警惕OR查询中字段名写错（如把apple_id写成app_id）导致全表扫描 - 删掉所有
SELECT *，改用明确字段列表——宽表 + 并行读 = 更多内存拷贝和网络传输，不是更快 - 对高频大表扫描场景，建函数索引（如
CREATE INDEX idx_year_created ON orders ((YEAR(created_at)));），避免WHERE YEAR(create_time) = 2025这种写法直接废掉索引
并行是锦上添花，索引和语句结构才是生死线。一个没走索引的查询，开 64 个线程也还是慢；而一个命中覆盖索引的查询，单线程可能比并行全扫快十倍。
