--default-parallelism合理值需匹配硬件：默认2（轻量环境），推荐4（8核+nvme中型库），0为禁用；实际线程数受限于表数量，且应结合--parallel-schemas按库定制并发以提升资源利用率。
mysqlpump --default-parallelism 参数怎么设才合理
并行线程数不是越多越好，它直接受限于服务器 CPU 核心数和磁盘 I/O 能力。设太高反而导致上下文切换开销增大、I/O 争抢严重，备份速度不升反降。
常见建议值如下：
-
--default-parallelism=2：默认值，适合轻量级环境或 SSD + 4核以下机器 -
--default-parallelism=4：多数中型生产库（16GB内存、8核CPU、NVMe盘）的推荐起点 -
--default-parallelism=0：强制关闭并行，仅当遇到锁表冲突或一致性报错时临时回退用
注意：mysqlpump 的并行单位是“表”，不是“行”或“页”。如果一个库只有 3 张大表，即使设 --default-parallelism=8，实际也最多启用 3 个线程——其余空闲。
为什么 --parallel-schemas 比 --default-parallelism 更精准
当多个数据库大小差异极大（比如 orders 占 200GB，logs 只有几百MB），统一用 --default-parallelism 会浪费资源：logs 库被强行分配多线程，而 orders 中的大表仍只能单线程处理单张表。
--parallel-schemas 允许你按库定制并发策略：
-
--parallel-schemas=8:orders,analytics：给orders和analytics各分配 8 个线程队列 -
--parallel-schemas=2:logs,config：小库只配 2 线程，避免过度调度 - 可混用：
--parallel-schemas=8:orders --default-parallelism=2，未显式指定的库走默认值
该参数在 MySQL 5.7.11+ 才稳定支持；低于此版本可能触发 ERROR 1290 (HY000) 或数据不一致。
备份时加 --defer-table-indexes 为什么能加快还原速度
mysqlpump 默认行为是：先 CREATE TABLE（含所有索引），再逐行 INSERT，最后 ALTER TABLE ... ENABLE KEYS。这对大表非常低效——每条 INSERT 都要维护二级索引。
加上 --defer-table-indexes 后，导出 SQL 会变成三阶段：
- 只建表结构（不含二级索引）
- 批量插入全部数据
- 最后统一
CREATE INDEX
实测对千万级以上表，还原耗时可降低 30%~60%。但要注意：导出文件体积略大（因索引定义拆到末尾），且恢复时需确保目标库 innodb_buffer_pool_size 足够容纳重建索引所需内存。
压缩输出用 LZ4 还是 ZLIB？别只看压缩率
--compress-output=LZ4 和 --compress-output=ZLIB 都能减小备份体积，但适用场景不同：
-
LZ4：压缩/解压速度极快（CPU 占用低），压缩率约比 ZLIB 低 15%～20%，适合备份窗口紧、CPU 敏感的环境 -
ZLIB：压缩率高（通常小 20%～30%），但加压/解压慢、CPU 消耗高，适合存储空间紧张、带宽受限（如跨公网传输）的场景 - 不推荐
NONE直接输出大库，容易撑爆磁盘或管道缓冲区
解压命令必须匹配算法：lz4 -d backup.sql.lz4 | mysql -u root -p，用 gzip -d 会失败并报 invalid compressed data。
真正影响效率的从来不是参数本身，而是你是否验证过它的效果——比如用 time mysqlpump ... > /dev/null 对比不同 --default-parallelism 值的实际耗时，而不是凭经验拍脑袋设 8 或 16。
