mysqlpump并非生产环境“高速备份”主力工具，因其本质是逻辑备份，仅支持数据库/表粒度并行导出，无法真正热备，大表仍串行、GTID配置易错、压缩非文件级，速度远逊XtraBackup。
mysqlpump 不是 MySQL 8.0 的“高速备份”主力工具，它比 mysqldump 略快但远不如 XtraBackup，且不支持真正意义上的热备份 —— 备份期间 DDL 操作（如 DROP TABLE、ALTER TABLE）可能被阻塞或失败。
为什么 mysqlpump 并不适合生产环境的“高速备份”
mysqlpump 是 MySQL 5.7 引入、8.0 延续的逻辑备份工具，本质仍是 SQL 导出。它的“并行”仅体现在：按数据库/表粒度分发导出任务到多个线程，但每个线程仍需走一遍 SQL 解析、权限校验、结果集序列化等流程，IO 和 CPU 利用率远低于物理备份工具。
常见错误现象包括：
- 对大表执行
mysqlpump --include-tables=big_table时，单表仍串行导出，--default-parallelism不生效 - 启用
--set-gtid-purged=ON时，若 GTID 已 purged，会直接报错ERROR 1236 (HY000)中断整个备份 - 使用
--compress后，客户端解压失败导致 SQL 文件损坏（该参数实际作用于网络传输层，非文件压缩）
mysqlpump 的并行参数怎么设才有效
mysqlpump 的并行能力高度受限于对象结构，并非所有场景都能触发多线程。关键在于明确哪些操作可并行、哪些必须串行：
-
--default-parallelism=N：仅控制「数据库级」并发数。例如有 10 个库，N=4表示最多同时导出 4 个库；若只有 1 个库，则始终单线程 -
--defer-table-indexes：把CREATE INDEX语句延迟到数据导入后再执行 —— 这不是并行优化，而是减少单表导出时的锁等待，对恢复阶段有意义，不影响备份速度 -
--skip-definer：跳过视图/存储过程中的 DEFINER 子句，避免因用户不存在导致导出失败，和并行无关但常被误配 - 真正提升吞吐的其实是
--compress（压缩网络流）+--single-transaction（InnoDB 快照），但这两项与线程数无关
一个典型可用命令：
xtrabackup --backup --defaults-file=/etc/my.cnf --target-dir=/backup/full
注意：上面这行是 XtraBackup 命令，不是 mysqlpump —— 因为 mysqlpump 几乎无法写出“稳定高速”的通用备份命令。你如果真在跑千万级表，mysqlpump -u root -p --default-parallelism=8 --databases db1 db2 db3 可能只比 mysqldump 快 15%～20%，而 xtrabackup 能快 5～10 倍且全程不锁表。
什么时候可以考虑用 mysqlpump
仅适用于以下明确场景：
- 备份目标是跨版本迁移（如 MySQL 5.7 → 8.0），需要兼容性更强的 SQL 文本
- 只备份少量小库（
- 环境受限无法安装 XtraBackup（如某些容器平台禁止挂载
/proc或访问datadir） - 需要精细控制导出内容，比如用
--exclude-tables=db1.log_*排除日志表 —— mysqldump 不支持通配符排除，mysqlpump 支持
此时建议最小化并行开销：--default-parallelism=2 即可。开太高反而因线程调度竞争导致整体变慢，尤其在磁盘 IOPS 不足时。
真正容易被忽略的一点：mysqlpump 导出的 SQL 文件默认不含 USE 语句，恢复时必须手动指定数据库，否则所有 CREATE TABLE 都会建到 test 库下 —— 这个坑比并行参数配置重要得多。
