mysqlpump --default-parallelism=0 强制禁用并行，实际为单线程；默认值即为0，不显式设≥1则永不启用并行，即使多核多库也仅用1线程，且仅表结构和数据块可并行，函数、视图、触发器等始终串行。
mysqlpump --default-parallelism=0 就是单线程，不是“默认自动并行”
很多人看到 --default-parallelism 这个参数名，下意识以为设了就启用并行，其实它默认值是 0 ——这代表「强制禁用并行」。不显式指定 ≥1 的值，mysqlpump 会老老实实单线程跑完所有内容，哪怕你机器有 64 核、备份 200 个库也只用 1 个线程。
常见错误现象包括：top 看到 CPU 始终单核满载、SHOW PROCESSLIST 里只出现 1 个 Dump 线程、日志里没有并发对象提示。这不是工具坏了，是根本没开并行。
-
--default-parallelism=4表示「每个数据库内最多并行处理 4 个独立对象」，不是全局总线程数 - 若只备份单库且该库只有 1 张表，即使设
--default-parallelism=8，实际也只启动 1 个线程导出那张表 - 想真正触发多线程，得满足两个条件：有足够多的库或表（≥ 并行数），且用户权限足够（如需
--single-transaction，还得有RELOAD权限）
哪些对象能并行，哪些永远串行？
mysqlpump 的并行不是按行、按语句，而是按「对象类型 + 独立性」分发任务。能真正并发的只有两类：
- 每张表的
CREATE TABLE语句（结构） - 每张表的数据块（
INSERT语句，按 chunk 拆分）
以下对象无论你怎么调参数，都始终串行执行：
-
CREATE FUNCTION、CREATE PROCEDURE、CREATE EVENT -
CREATE USER、GRANT（除非加--users且权限足够） -
CREATE VIEW和CREATE TRIGGER，除非加--skip-definer避开权限校验阻塞
典型场景：一个库含 150 张小表 + 20 个存储过程。设 --default-parallelism=6，前段表结构和数据导出能跑满 6 线程，但一到函数导出阶段就会卡住主线程，等全部串行做完才继续——这部分时间完全无法加速。
单库备份时，并行经常失效，试试 --parallel-schemas
对单库场景，--default-parallelism 很难起效，因为并行粒度是「库内对象数」，而单库对象再多，也受限于锁、事务隔离或依赖关系。更可靠的做法是用 --parallel-schemas 显式拆分库级任务：
-
--parallel-schemas=4:db1,db2,db3表示为db1、db2、db3各分配最多 4 个线程（共最多 12 线程） - 哪怕你实际只备份
db1，也可以伪造多个库名：--parallel-schemas=4:db1,db1_dummy（前提是db1_dummy存在或被--include-databases显式包含，否则会被跳过） - 比单纯写
mysqlpump -u u -p db1更容易触发并行，尤其当库内表数远大于并行数时
注意：--parallel-schemas 要求目标库存在，且用户对它们都有访问权限；若权限不足，会静默跳过该库，导致并行线程数骤减。
MySQL 8.0.34+ 已弃用 mysqlpump，别在新环境部署
截至 2026 年 10 月，mysqlpump 在 MySQL 8.0.34 及之后版本已被官方标记为 deprecated，2026 年起不应再用于新部署。它最大的硬伤是：只支持多线程导出，导入仍是单线程——这意味着备份快，恢复慢，RTO 不理想。
如果你还在用 8.0.33 或更早版本，务必清楚这些限制：
- 导出后不能直接用
mysql -u root -p 导入：含 <code>DEFINER的视图/过程可能报错ERROR 1227 (42501)，CREATE USER语句在目标实例无权限时也会失败 - 推荐安全导入方式：
mysqlpump -u u -p db1 | mysql -u u -p db1（跳过文件落地，但要求源/目标字符集一致、网络稳定） - 更现代的替代方案是 MySQL Shell 的
util.dump_instance()，支持导出+导入双多线程，且兼容 GTID、压缩、进度反馈等
真正容易被忽略的点是：并行效果高度依赖「对象分布」和「权限完整性」。测试时别只看命令是否报错，要盯 SHOW PROCESSLIST、查日志里的 Dump 线程数、确认是否真有多个对象在同时导出——否则你只是在假装并行。
