mysqlpump --default-parallelism=8仍单线程，因其默认值为0且需多库/多表及足权才触发并行；单库单表或权限不足（如缺select、reload）时自动降级，验证须用--dry-run检查对象列表。

mysqlpump --default-parallelism=8 为什么还是单线程？

因为 --default-parallelism 默认值是 0，不显式设就等于禁用；而且它只在「有多个可并行对象」时才起作用。比如你只备份一个库、一张表，哪怕设成 --default-parallelism=16，也只会启动 1 个线程。

常见错误现象：

• mysqlpump -u root -p mydb CPU 始终占满单核，速度和 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 处理

线程数不是越多越好：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 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 减小传输量（注意：这是网络层压缩，不是文件压缩）

真正影响备份速度的，从来不是线程数本身，而是对象结构分布、权限配置、以及你有没有避开那些必然串行的环节。