MySQL 8.0 存储过程中无法利用innodb_parallel_read_threads加速SELECT，因其仅对无索引全表扫描且无LIMIT/GROUP BY/子查询等的简单查询生效，而存储过程不改变执行模型，应用层分片并发才是有效提速方案。
MySQL 8.0 存储过程中无法直接利用 innodb_parallel_read_threads 加速普通 SELECT 查询。这个参数对存储过程内的语句基本无效，不是配置了就能提速——它只在极少数后台物理扫描场景下起作用，且不改变查询逻辑或执行计划。
为什么存储过程里设了 innodb_parallel_read_threads 也没用
存储过程本质是 SQL 语句的封装容器，不改变底层执行模型。而 innodb_parallel_read_threads 的生效前提非常苛刻：
- 仅对 InnoDB 表的无索引全表扫描（
type=ALL）生效，且必须是简单 WHERE（如WHERE id > 1000），不能含LIMIT、GROUP BY、子查询、窗口函数 - 存储过程内常见的带变量参数查询（如
WHERE status = p_status）极易触发隐式类型转换或执行计划不稳定，导致优化器跳过并行路径 - 该参数影响的是 InnoDB 内部读取线程数，不是查询调度器；存储过程中的 SELECT 仍由单线程 SQL 层驱动，不会自动拆分任务
- 即使你在过程开头执行
SET SESSION innodb_parallel_read_threads = 4，后续 SELECT 也大概率不触发并行——因为 EXPLAIN FORMAT=TREE 不显示Parallel scan就说明没走
存储过程内真正能提速的并行思路：应用层分片 + 并发调用
想让“大范围读取”变快，得绕开 MySQL 服务端限制，在调用方做并发控制：
- 把原存储过程里的大查询逻辑（如统计某类用户行为）按主键/时间范围切分成多个互斥子查询：
WHERE id BETWEEN 1 AND 100000、BETWEEN 100001 AND 200000… - 在应用代码中用连接池并发发起这些子查询（例如 Python 的
asyncio.gather()或 Java 的CompletableFuture.allOf()） - 结果在应用层合并（注意去重、排序逻辑不能下推到数据库，否则又回到单线程瓶颈）
- 避免在存储过程内部尝试循环调用同类查询——那只会串行放大延迟，还可能引发锁等待或连接耗尽
别踩坑：innodb_parallel_read_threads 常见误用场景
这些操作看似“开了并行”，实际毫无效果，甚至有害：
- 在存储过程里写
SET GLOBAL innodb_parallel_read_threads = 4—— 会话级 SET 不支持 GLOBAL，报错；且 GLOBAL 设置需重启才生效，过程内不可达 - 对带
ORDER BY ... LIMIT 50的报表查询启用该参数 ——LIMIT强制终止扫描，优化器直接禁用并行 - 给 MyISAM 表或分区表（哪怕子分区是 InnoDB）设该参数 —— 完全不支持，EXPLAIN FORMAT=TREE 永远看不到 Parallel scan
- 设成 16 或 32 —— 超过 CPU 核心数后线程争抢 I/O 和内存，实测响应反而更慢；建议 ≤ CPU 核心数 × 1.5
最容易被忽略的一点：存储过程的性能瓶颈几乎从来不在“是否并行”，而在索引缺失、参数类型不匹配、重复计算或事务隔离级别拖累。先用 EXPLAIN 确认那条 SELECT 是否走了索引，比折腾 innodb_parallel_read_threads 实用十倍。
