mysqlpump默认不并行，必须显式指定--default-parallelism=N（N>0）才启用多线程；仅表结构和数据支持并行，函数、权限等仍串行，且需满足多库或多表等对象分片条件才能真正并发。
mysqlpump 默认不并行，必须显式启用才能真正跑满多核——哪怕你有 32 核 CPU，不加参数它也只用 1 个线程干活。关键不是“能不能”，而是“怎么配才真并发”。
为什么 --default-parallelism 设了却没效果？
常见现象：CPU 始终单核满载，SHOW PROCESSLIST 里只看到 1 个 Dump 线程，备份时间跟 mysqldump 差不多。
根本原因不是参数写错，而是两个硬性条件没满足：
• 数据库中要有足够多的独立对象（至少 2 个以上库，或单库内 ≥4 张表）——mysqlpump 按库/表分片并行，单库单表再大也只起 1 个线程
• 用户权限不足：除 SELECT 外，若用了 --single-transaction 还需 RELOAD；导出用户得对 mysql 库有 SELECT 权限；否则会静默跳过对象，实际并行数归零
建议先跑一次干运行：mysqlpump -u u -p --all-databases --dry-run，确认输出里真列出了所有库和表
多库并行最稳的写法是 --include-databases
直接写 mysqlpump -u root -p db1 db2 db3 容易被当成单库上下文处理，并行度受限；而显式用 --include-databases 能强制触发库级分片：
• 正确示例：mysqlpump -u root -p --include-databases=db1,db2,db3 --default-parallelism=4 > backup.sql
• 它会为每个库单独分配线程池，比拼接参数更可靠
• 如果库数量多（比如 10+），可搭配 --parallel-schemas=6:core_db,log_db 对重点库单独提权，其余走默认值
• 注意：线程数不是越多越好——SSD 上建议 ≤8，HDD 上 ≤4；超过物理核心数后 I/O 争抢反而拖慢整体速度
导入时别直接管道执行压缩文件
mysqlpump 生成的 LZ4/ZLIB 压缩文件不能直接 mysql -u root -p ：<br>• <code>--compress-output=LZ4 输出的是二进制压缩流，mysql 客户端无法识别
• 必须先解压：lz4 -d backup.lz4 | mysql -u root -p
• 更麻烦的是兼容性问题：默认导出含 CREATE USER 和带 DEFINER 的视图，目标实例若无 CREATE USER 权限或缺失对应账号，会卡在 CREATE ALGORITHM= 行
• 解法是加 --skip-definer --users 分离权限导出，或用 --skip-users 彻底跳过用户部分
MySQL 8.0.34+ 用户该考虑迁移了
mysqlpump 在 MySQL 8.0.34 及之后版本已被官方标记为 deprecated，2026 年起不应再用于新部署。
它只支持多线程导出、单线程导入，RTO 实际并不理想；且 --default-parallelism 对函数、事件、GRANT 等全局对象完全无效，这些仍串行处理。
真正双多线程（导出+导入都并发）的替代方案是 MySQL Shell 的 util.dump_instance()，支持 chunk 级并行、自动重试、进度回调——但要注意它不生成 SQL 文件，而是目录结构，恢复方式完全不同。
