mysqlpump默认不启用多线程，必须显式指定--default-parallelism或--parallel-schemas才能触发并行导出；它仅对库/表级对象并发，单库单表或权限不足时仍降为单线程，且导入始终需外部并发执行。
mysqlpump 默认不启用多线程，必须显式指定参数才能触发并行导出。它只在满足对象分片条件和权限要求时才真正并发，且导入仍是单线程——别指望靠它缩短恢复时间。
为什么 mysqlpump 加了 --default-parallelism=8 还是单线程跑？
根本原因：并行不是“开了就生效”，而是依赖两个硬性前提：
-
--default-parallelism默认值是0，不是2或自动检测；不写等于禁用 - 它按库或表分片并行，若只备份单个库里的 1 张大表，哪怕设成
--default-parallelism=16，也只起 1 个线程 - 权限不足会导致对象列表为空，进而降级为单线程：比如缺
RELOAD权限时--single-transaction失效，或对mysql库无SELECT权限时无法列出用户
验证方式：mysqlpump -u u -p --all-databases --dry-run 看是否能列出所有库和表；如果日志里出现 Warning: Skipping dump of database xxx: no tables found，基本就是权限问题。
--default-parallelism 和 --parallel-schemas 怎么选？
前者是全局兜底值，后者是精准控制。实际生产中后者更可靠：
-
--default-parallelism=4：对所有参与备份的库，每库最多开 4 线程处理其内部表（但若某库只有 1 张表，仍只用 1 线程） -
--parallel-schemas=6:app_db,log_db：明确只为app_db和log_db开 6 线程，并跳过其他库的并行逻辑 - 混用时，
--parallel-schemas优先级更高；未被--parallel-schemas覆盖的库才走--default-parallelism - 线程数不是越多越好：SSD 上建议 ≤ 8，HDD 上 ≤ 4；超过物理核数后 I/O 竞争反而拖慢整体速度
哪些对象真能并行？哪些只是“假装多线程”？
mysqlpump 的并行粒度很细，但并非所有 SQL 都能拆开跑：
- ✅ 真正并行：每张表的
CREATE TABLE+ 对应的INSERT数据块（按 chunk 分片），这是提速主力 - ❌ 串行执行：
CREATE FUNCTION、CREATE USER、GRANT、CREATE EVENT、视图定义（含DEFINER）等全局对象，全部排队等主线程干完 - ⚠️ 注意
--skip-definer：大量带DEFINER的视图/函数会卡在权限检查阶段，导致并行效果打折，建议加上 - ⚠️ 大表容易 OOM：默认 chunk 太大或并发太高时，客户端内存飙升，可能被系统
Killed；可加--chunk-filesize=50控制单次读取量
备份后怎么安全导入？别直接 mysql -u root -p
mysqlpump 输出格式与 mysqldump 不完全兼容，直接重定向常失败：
- 含
CREATE USER/GRANT的备份，在目标实例没CREATE USER权限时报错：ERROR 1227 (42501): Access denied; you need (at least one of) the CREATE USER privilege(s) - 压缩文件（如
--compress-output=LZ4）不能管道直入，必须先解压：lz4 -d backup.sql.lz4 | mysql -u u -p db_name - 推荐做法：
mysqlpump -u u -p db1 | mysql -u u -p db1（跳过文件落地，但要求源/目标字符集一致、网络稳定） - 更稳妥：加
--skip-definer和--users显式控制，避免隐式权限绑定
现在 mysqlpump 在 MySQL 8.0.34+ 已标记为 deprecated，2026 年起不应用于新部署；如果只是临时过渡，务必确认版本，并意识到它只解决“导出快”，不解决“恢复慢”。
