MySQL不支持单条SELECT的并行执行；innodb_parallel_read_threads仅用于ANALYZE TABLE等后台只读扫描，不影响普通查询；真正提升I/O吞吐的是innodb_read_io_threads等后台线程，但它们不参与查询并行化。
MySQL根本不执行“并行查询”，innodb_parallel_read_threads 不参与普通 SELECT
MySQL 服务端原生不支持单条 SQL 的并行执行（比如把一个 SELECT COUNT(*) FROM t 拆成 4 个线程各自 COUNT 再汇总）。所谓“并行查询”是常见误解——innodb_parallel_read_threads 参数仅在极少数后台只读扫描场景下生效，例如 ANALYZE TABLE 或某些 SELECT ... INTO DUMPFILE，且完全不影响普通查询的执行计划、EXPLAIN 输出或执行路径。它不会让任何用户发起的 SELECT 自动启用多线程扫描。
innodb_read_io_threads 和 innodb_write_io_threads 才是真正干活的后台 I/O 线程
这些线程负责处理磁盘层面的异步读写请求，但它们不是为“查询并行化”设计的，而是为提升 I/O 吞吐服务的。关键事实：
- 必须在
my.cnf中静态配置，重启 MySQL 才生效；无法SET GLOBAL动态修改 -
innodb_read_io_threads默认为 4，最大可设 64；每个线程最多并发处理 256 个 pending 读请求 → 总并发读能力上限 = 线程数 × 256 - 线程调度按空间局部性优化：同一
extent（64 页 = 1MB）的读请求尽量交给同一个线程，便于合并 I/O、减少寻道 - 这些线程响应的是 InnoDB 内部触发的 I/O，比如预读（read-ahead）、脏页刷新、LRU 页淘汰、检查点写入——不是响应你写的 SQL
真正能实现“并发拉取”的只有应用层分片 + 多连接
如果你需要加速大表扫描、聚合或 ETL 类任务，唯一可控、通用的方式是：在应用中把逻辑拆开，用多个连接并发执行子查询。例如：
- 按主键范围切分：
SELECT SUM(amount) FROM orders WHERE id BETWEEN 1 AND 100000、BETWEEN 100001 AND 200000… - 用连接池控制并发度（如 Python 的
asyncio.gather、Java 的CompletableFuture），避免打爆max_connections（默认 151） - 注意事务隔离级别：并发读可能遇到不可重复读，报表类查询通常可接受；但若需强一致性，应加锁或改用串行执行
- 物理资源瓶颈常在磁盘吞吐或 CPU：即使开了 20 个并发查询，若 I/O 饱和或 buffer pool 命中率暴跌，整体耗时反而上升
容易被忽略的关键点：I/O 线程不等于查询线程，也不共享查询上下文
很多人误以为调高 innodb_read_io_threads 就能让 SELECT 变快，但实际效果往往微乎其微。因为：
- 前台查询线程（每个客户端连接对应一个）只负责解析、优化、生成执行计划、协调缓冲池访问；真正的磁盘读由后台 I/O 线程异步完成，但这个过程对 SQL 层完全透明
- I/O 线程之间不通信、不协作执行同一查询；它们只是被动响应 InnoDB 存储引擎发出的读页请求队列
- 如果查询能走索引+内存命中，根本不会触发磁盘读 → 此时调高 I/O 线程数毫无意义
- 真正卡住查询性能的，往往是锁竞争、buffer pool 不足、排序/临时表落盘，而非 I/O 线程数量
