mysqlpump --default-parallelism=8仍单线程，因其默认值为0且需多库/多表及足权才触发并行；单库单表或权限不足（如缺SELECT、RELOAD）时自动降级，验证须用--dry-run检查对象列表。
mysqlpump --default-parallelism=8 为什么还是单线程？
因为 --default-parallelism 默认值是 0，不显式设就等于禁用；而且它只在「有多个可并行对象」时才起作用。比如你只备份一个库、一张表，哪怕设成 --default-parallelism=16，也只会启动 1 个线程。
常见错误现象：
-
mysqlpump -u root -p mydbCPU 始终占满单核，速度和mysqldump差不多 - 日志里出现
Warning: Skipping dump of database xxx: no tables found，说明权限不足导致对象列表为空，自动降级为单线程
验证是否真能并发：
- 先跑一次干运行：
mysqlpump -u u -p --all-databases --dry-run，看能否列出所有库和表 - 检查用户权限：至少要有
SELECT（所有目标库）、RELOAD（用于--single-transaction）、SHOW DATABASES
--default-parallelism 和 --parallel-schemas 哪个该用？
--parallel-schemas 更可靠，尤其当你要精准控制哪些库参与并行时。它优先级高于 --default-parallelism，未被覆盖的库才走后者。
典型用法：
-
--default-parallelism=4：所有库最多每库开 4 线程 —— 但若某库只有 1 张表，仍只用 1 线程 -
--parallel-schemas=6:app_db,log_db：只对app_db和log_db启用 6 线程，并跳过其他库的并行逻辑 - 混用时，
app_db走 6 线程，report_db若没被--parallel-schemas列出，则按--default-parallelism=4处理
线程数不是越多越好：
- SSD 上建议 ≤ 8，HDD 上 ≤ 4
- 超过物理 CPU 核数后，I/O 竞争反而拖慢整体速度
哪些操作真能并行？哪些只是“假多线程”？
mysqlpump 的并行粒度是「表级」，不是「SQL 语句级」。它把每张表的 CREATE TABLE 和对应 INSERT 数据块（按 chunk 分片）分发给不同线程，这是唯一真正提速的部分。
以下对象始终串行执行，会卡住主线程：
-
CREATE FUNCTION、CREATE PROCEDURE -
CREATE USER、GRANT、CREATE EVENT - 视图定义（含
DEFINER），除非加--skip-definer
容易被忽略的影响：
- 如果库中函数/事件/视图数量远超表数，开再多线程也没用，瓶颈在串行阶段
- 大量带
DEFINER的对象会触发权限检查，阻塞并行流程 —— 加--skip-definer很关键
大表备份时 OOM 或锁表怎么办？
默认 chunk 太大 + 并发太高，客户端内存容易爆，系统直接 Killed；同时 --single-transaction 在某些隔离级别下可能引发元数据锁（MDL），阻塞线上 ALTER TABLE。
实操建议：
- 加
--chunk-size=500000（比默认 1000000 小一半），降低单次读取内存压力 - 必须加
--single-transaction，否则无法保证一致性快照 - 避免对单张超大表单独使用
--include-tables：即使设了--default-parallelism=8，它也只起 1 个线程导出这张表 - 导出文件体积大时，用
--compress-output=LZ4减小传输量（注意：这是网络层压缩，不是文件压缩）
真正影响备份速度的，从来不是线程数本身，而是对象结构分布、权限配置、以及你有没有避开那些必然串行的环节。
