MySQL原生不支持单条SQL并行执行；innodb_parallel_read_threads仅影响特定后台操作的内部读取线程数，不加速普通查询；真正可行的并行方案是应用层分片并发执行或使用mysqlpump并行导出。
MySQL 原生不支持单条 SQL 的并行执行（如 PostgreSQL 的 parallel query），所谓“并行查询”在 MySQL 中通常指通过应用层或架构设计实现的并发执行，而非服务端自动并行化。
为什么 MySQL 8.0+ 的 innodb_parallel_read_threads 不等于并行查询
这个参数仅影响 InnoDB 在执行某些后台操作（如 ANALYZE TABLE 或部分 SELECT ... INTO DUMPFILE 场景）时的内部读取线程数，它不会让普通 SELECT 语句并行扫描或并行 JOIN。开启后对 OLTP 查询几乎无加速效果，且默认值为 0（禁用）。
-
innodb_parallel_read_threads仅在特定只读、大范围物理扫描场景下生效，且需配合innodb_read_io_threads调优 - 即使设为 4，也不会把一个
SELECT COUNT(*) FROM huge_table拆成 4 个线程并行 COUNT - 该参数不影响查询优化器行为，也不改变执行计划中的
EXPLAIN输出
真正可用的“并行”方案：应用层分片 + 并发执行
当需要加速全表聚合、范围扫描或 ETL 类任务时，最常用且可控的方式是：在应用中将大查询逻辑拆分为多个互不重叠的子查询，再并发发起。
- 按主键/时间范围切分：例如
WHERE id BETWEEN 1 AND 100000、BETWEEN 100001 AND 200000… - 用
UNION ALL合并结果前，先用连接池（如 Python 的asyncio.gather或 Java 的CompletableFuture）并发执行多个SELECT - 注意事务隔离级别：并发读可能遇到不可重复读，但对报表类查询通常可接受
- 避免过载：MySQL 默认
max_connections通常为 151，实际并发子查询数建议 ≤ 20，视服务器 CPU 和 I/O 能力调整
替代思路：用 mysqldump 或 mysqlpump 实现并行导出
虽然不是“执行 SQL”，但在大批量数据抽取场景中，这是更高效、更稳定的并行实践。
-
mysqlpump（MySQL 5.7+）原生支持--default-parallelism=N，可并行导出多个库或多个表 - 示例：
mysqlpump --user=root --default-parallelism=4 mydb table1 table2 table3
-
mysqldump本身不支持并行，但可通过 shell 脚本启动多个进程分别 dump 不同表，再用--where限定范围实现逻辑并行 - 注意：并行导出会显著增加磁盘 I/O 和网络带宽压力，生产环境需错峰执行
MySQL 的查询执行本质是单线程模型，所有“并行”都绕不开应用层协调或工具链支持。最容易被忽略的一点是：盲目增加并发数反而引发锁争用、CPU 上下文切换开销和连接耗尽，实测中 4–8 路并发往往比 16 路更快。先做小规模切分压测，再扩并发，比直接调高数字更有效。
