MySQL 8.0 并行查询仅对满足全部条件的全表扫描有效：普通InnoDB表、type=ALL、无索引WHERE、无LIMIT/ORDER BY/GROUP BY/子查询等、仅COUNT(*)且行数超百万；必须用EXPLAIN FORMAT=TREE验证，其他方式不可靠。
MySQL 8.0 的并行查询框架对单条复杂 SQL 几乎无效——它不处理复杂逻辑，只加速特定物理扫描。想靠 innodb_parallel_read_threads 让带 GROUP BY、LIMIT、ORDER BY 或子查询的语句变快，基本没戏。
哪些 SQL 真正可能触发 Parallel scan？
必须同时满足全部条件，缺一不可：
- 目标表是普通 InnoDB 表（非分区表、非临时表、非 MyISAM）
- 执行计划最外层是
type=ALL（全表扫描），且WHERE条件完全无法使用任何索引（例如WHERE status = 'ERROR'，而status列无索引） - 语句不含
LIMIT、DISTINCT、UNION、CTE、派生表、窗口函数 - 没有
GROUP BY；聚合仅限COUNT(*)（且不保证一定并行），COUNT(id)、SUM(amount)等明确拒绝并行 - 扫描行数足够大（通常 > 百万行），否则优化器判定并行开销不划算
EXPLAIN FORMAT=TREE 是唯一可信验证方式
其他方式全是误导：
-
EXPLAIN或EXPLAIN FORMAT=JSON完全不显示并行信息，哪怕输出里有"parallel_table_scan": true，实际也可能降级为单线程 -
SHOW VARIABLES LIKE 'innodb_parallel_read_threads'返回 4，不代表当前查询已启用并行——它只是个开关阈值，不是生效标志 - 只有
EXPLAIN FORMAT=TREE输出中出现Parallel scan on table_name，才代表真正启用 - 如果看到
Using index（覆盖索引），哪怕表再大，也根本不会触发并行——因为不走物理页读取，innodb_parallel_read_threads对它完全无效
如何安全设置 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 就顶天了，再多线程争抢磁头寻道，延迟反升
- 该参数是会话级的，
SET GLOBAL不影响已存在的连接；生产长期生效需写入my.cnf的[mysqld]段 - 注意：它控制的是“每个满足条件的查询最多可用的后台线程数”，不是全局并发池；系统满载（CPU > 90%、buffer pool mutex 竞争高）时强行开多线程，反而加剧锁争用
并行扫描真正在工作？别只信 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增长速率：并行下后者应明显快于前者，说明数据读取被分摊
真正容易被忽略的是：并行只发生在存储引擎层（InnoDB）的物理扫描阶段，执行器（server layer）仍串行合并结果。一旦 SQL 带 ORDER BY 或 GROUP BY，后续排序/分组就变成新瓶颈，甚至因并行打乱顺序而额外消耗内存——这时候调 innodb_parallel_read_threads 已毫无意义。
