mysql 8.0并行查询仅加速满足严格条件的聚簇索引全表或大范围扫描，不支持二级索引扫描、聚合、limit等；必须设innodb_parallel_read_threads>0且explain format=tree显示“parallel scan”才生效。
innodb_parallel_read_threads 对大表索引扫描没有显著加成——这是个常见误解。MySQL 8.0 的并行执行框架不加速索引扫描，只加速特定条件下的全表扫描（聚簇索引扫描）。
真正能触发并行的，是 type=ALL 或退化为大范围 type=range 的扫描，且必须满足：无有效索引可用、无 LIMIT、无 GROUP BY、无子查询、事务隔离级别不是 REPEATABLE READ 下的 gap lock 场景等硬约束。
为什么“索引扫描”通常不并行？
因为 MySQL 8.0 的并行能力仅实现在 InnoDB 存储引擎的物理页读取层，且**只对聚簇索引（主键）的顺序扫描路径启用**。二级索引扫描走的是 B+ 树导航 + 回表路径，无法分片调度；即使 WHERE created_at > '2025-01-01' 触发了大范围 range 扫描，只要优化器选了二级索引，就不会启动并行。
-
EXPLAIN FORMAT=TREE输出里出现Parallel scan on table_name—— 才算真并行；若看到Index range scan on idx_created，就说明没并行 - 覆盖索引（
Extra: Using index）完全绕过磁盘页读，innodb_parallel_read_threads对它无效 - 哪怕
innodb_parallel_read_threads=16，对SELECT * FROM t WHERE id = ?这类const或ref查找毫无影响
什么情况下“看似索引扫描”却可能并行？
只有当优化器判定“无法用索引高效定位”，被迫回退到聚簇索引扫描时，才可能并行。典型场景包括：
- WHERE 条件中字段无索引，或索引选择性极低（如
status IN ('A','B','C')占全表 80% 行） - 复合索引最左前缀未被使用（如索引
idx(a,b,c)，但查询只用WHERE c = 1） - 隐式类型转换导致索引失效（如
WHERE phone = 13800138000，phone 是 VARCHAR）
此时 EXPLAIN 显示 type=ALL 或 type=range 且 key=NULL 或 key=PRIMARY，再配合 EXPLAIN FORMAT=TREE 确认 Parallel scan，才算真正受益。
为什么调高 innodb_parallel_read_threads 反而变慢？
并行线程数不是越多越好。它只控制单次扫描最多启用的后台线程数，但实际效果受底层资源制约：
- CPU 已满载时，多线程争抢调度，反而增加上下文切换开销
-
innodb_buffer_pool_size不足时，并行线程争抢 buffer pool mutex，引发锁等待 - SSD 场景下超过
16基本无收益；HDD 下设2–4就是上限 - 并发多个大表扫描时，线程池共享，
innodb_parallel_read_threads是会话级参数，但底层 worker 是全局复用的，容易互相挤占
验证并行是否真起作用，别信参数值
光看 SHOW VARIABLES LIKE 'innodb_parallel_read_threads' 毫无意义。必须组合验证：
- 执行
EXPLAIN FORMAT=TREE SELECT ...，第一行必须是-> Parallel scan on table_name - 运行时查
performance_schema.threads，过滤出多个query exec类型线程（非connect或sleep） - 对比
Handler_read_rnd_next和Innodb_rows_read增速：并行下后者应明显快于前者，说明 I/O 被分摊
真正容易被忽略的是：并行只解决最慢的那个 I/O 路径，如果瓶颈在临时表、网络传输、执行器归并或锁竞争上，调参毫无价值。
