mysqldump 本身是单线程工具，--threads 等参数无效；真正提速需拆分任务并行调用多个实例，或改用支持原生多线程的 mysqlpump（mysql 5.7+），合理设置并行度避免 mdl 和 buffer pool 争用。
mysqldump 导出时并发线程数根本不起作用
因为 mysqldump 本身是单线程工具，无论加多少 --threads 或用 -p 并发参数，它都只开一个连接、一条 SQL 流水线地 dump。你看到的“多线程”往往是外部脚本并行调用多个 mysqldump 实例，本质是靠 shell 控制，并非工具原生支持。
常见错误现象：mysqldump --threads=8 执行时 CPU 占用仍很低，导出时间没明显缩短；监控显示只有一个 mysqldump 进程在跑。
- 真正能提升导出速度的方式：按库或按表拆分任务，用
parallel或 shell 循环启动多个mysqldump进程 - 注意控制总连接数——每个
mysqldump都会占用一个 MySQL 连接，别超过max_connections限制 - 大表建议单独导出，避免单个 dump 文件过大导致内存溢出或网络中断重传失败
mysqlpump 支持真正的多线程导入导出
mysqlpump 是 MySQL 5.7+ 自带的替代方案，原生支持 --default-parallelism 和 --parallel-schemas，能按库/表级并发执行。它把逻辑备份拆成多个工作线程，每个线程负责一部分对象的 dump + 压缩 + 写入。
使用场景：MySQL ≥ 5.7，且目标实例支持足够高的 innodb_buffer_pool_size 和 max_connections。
- 推荐起始值：
--default-parallelism=4，再根据 CPU 核心数和磁盘 I/O 负载逐步调高（一般不超过 CPU 核数 × 1.5） - 避免设太高：线程太多会导致 InnoDB 行锁争用加剧，
SHOW PROCESSLIST中出现大量Waiting for table metadata lock - 导出时加
--compress-output=LZ4可降低网络和磁盘压力，但会增加 CPU 消耗
mysql 客户端导入时线程数由客户端决定，不是服务端
用 mysql -u root -p 导入时，整个文件是单线程顺序执行的。即使备份里有 100 张表，也是一条语句接一条语句执行，无法“自动并发”。所谓“调整导入进程数量”，其实是换思路：把大 SQL 拆成小块，用多个 <code>mysql 进程并行加载。
常见错误现象：导入卡在某张大表的 INSERT 上，LOAD DATA INFILE 没生效，CPU 利用率低，磁盘写入持续缓慢。
- 拆分方法：用
sed或split按CREATE TABLE或INSERT INTO `table_name`分割文件，生成 per-table SQL - 并发控制：用
parallel -j 4 mysql -u root -p db_name 启动 4 个导入进程，注意每进程必须指定不同数据库名或加 <code>--force忽略错表 - 关键前提：目标库已建好结构（先用
mysqlpump --no-data导出 schema 并导入），否则并发建表容易触发元数据锁冲突
Percona XtraBackup 的并发参数实际影响的是拷贝阶段
如果你走物理备份路线，xtrabackup 的 --parallel 控制的是文件拷贝线程数，--compress-threads 控制压缩线程数，而 --apply-log 阶段默认仍是单线程——这点很多人误以为“开了并发就全程加速”。
性能影响明显的地方：源库磁盘是 NVMe，目标是 SATA，且备份集 > 100GB 时，--parallel=4 能显著减少 cp 类操作耗时；但 --apply-log 仍可能成为瓶颈。
- 建议组合：
--parallel=4 --compress-threads=2 --use-memory=4G，避免内存超限触发 swap - 不要盲目设
--parallel=16：线程过多会让 ext4/xfs 的 inode 锁竞争变严重，实测反而比--parallel=4慢 15%~20% - 恢复时
xtrabackup --copy-back不支持并发，得等它跑完再手动chown和重启 mysqld
并发不是越多越好，核心是匹配你的 I/O 能力和锁竞争边界。最容易被忽略的是元数据锁（MDL）和 InnoDB buffer pool 的争用，而不是线程数本身。
