innodb_parallel_read_threads是MySQL 8.0.14新增的参数，用于控制聚簇索引扫描的并行线程数，不适用于二级索引，可提升CHECK TABLE等操作性能；MySQL 5.7不支持该参数。
innodb_parallel_read_threads 不是 MySQL 5.7 的参数 —— 它首次出现在 MySQL 8.0.14，5.7 版本压根不识别这个配置项。如果你在 5.7 的 my.cnf 里写了它，MySQL 启动时会静默忽略（不会报错），但也不会起任何作用。
真正影响 5.7 备份速度的，是备份方式本身和底层 IO 调度能力，而不是“并行读线程”这类 8.0 才有的机制。
mysqldump 备份慢的根本原因
-
mysqldump是单线程逻辑备份：逐表 SELECT → 序列化为 SQL → 写文件 - 没有并发导出能力，哪怕你加了
--single-transaction或--skip-extended-insert，也只是缓解解析压力，无法突破单线程瓶颈 - 表越大、索引越多、BLOB 字段越密集，单线程扫描和序列化耗时越长
- 若开启
slow_query_log或general_log，还会额外拖慢 dump 过程
常见错误现象：
- 备份一张 50GB 的 InnoDB 表耗时超 2 小时，且 CPU 利用率长期低于 30%
-
SHOW PROCESSLIST显示 dump 连接始终卡在Sending data状态
Percona XtraBackup 是 5.7 下唯一可行的提速方案
MySQL 5.7 原生不支持并行物理备份，但 xtrabackup（2.4.x 系列）完全兼容 5.7，且提供真正有效的加速手段：
-
--parallel=4：控制拷贝数据文件的并发进程数（不是线程，是 fork 出的子进程） -
--compress --compress-threads=4：压缩阶段并行化（需安装 qpress） -
--stream=xbstream+ 管道直传远程存储，避免本地磁盘中转 -
--use-memory=4G：仅在--prepare阶段生效，加速日志回放，不影响备份阶段速度
注意：
-
--parallel值不宜超过物理 CPU 核心数 × 1.5，否则反而因上下文切换增加开销 - 使用
--parallel时必须配合--rsync（默认启用），否则会退化为串行 - 不要对同一实例同时运行多个
xtrabackup备份任务，InnoDB 的全局锁竞争会导致整体变慢
为什么调大 innodb_read_io_threads 对备份没用
-
innodb_read_io_threads仅影响 InnoDB 内部后台预读、刷脏页、合并插入缓冲等操作，和客户端发起的 SELECT（mysqldump）或文件拷贝（xtrabackup）无关 -
xtrabackup是直接读取 ibdata1 / *.ibd 文件，绕过 MySQL Server 层，根本不走 InnoDB 的 IO 线程池 - 即使把
innodb_read_io_threads从默认 4 改成 16，在mysqldump场景下也观察不到 IO 利用率提升
你可以用以下命令验证是否真正在用这些线程：
SELECT * FROM performance_schema.threads WHERE NAME LIKE '%innodb%read%';正常负载下应看到 4 个活跃线程；但执行
mysqldump 时，它们基本处于 idle 状态。
备份慢这件事，本质是选错了工具层级。MySQL 5.7 没有 innodb_parallel_read_threads，也不该指望它。物理备份路径才是唯一出口，而所有“调参提速”的幻想，都会在 100GB 表面前迅速破灭。
