mydumper默认-t 4会拖慢大库备份，因其无法充分利用ssd与多核资源；需按cpu物理核心数1.2~1.5倍调优线程数，配合-r分片、--compress压缩、--secure_file_priv配置及file权限授权，才能真正释放并发性能。
mydumper 能显著提升 MySQL 海量数据备份效率，但不是“开箱即快”——它快的前提是线程、分片、权限、路径全对齐。盲目套默认参数，反而可能比 mysqldump 更慢。
为什么默认 -t 4 反而拖慢大库备份？
mydumper 默认只用 4 个线程，对 SSD + 16 核以上机器来说，CPU 和 IO 都吃不满，实测常压在 15%~20%。真正跑满资源需主动调参：
-
-t值建议设为 CPU 物理核心数的 1.2~1.5 倍（如 12 核机器用-t 14），超过 24 后收益递减，上下文切换开销反升 -
-r控制行级分片粒度：千万级表推荐-r 1000000；亿级表可压到-r 500000，避免单 chunk 扫描太久阻塞其他线程 -
--chunk-filesize 50强制按 50MB 切文件，防单文件超 2GB 导致 OOM 或网络传输中断（尤其走 rsync 或对象存储时） - 务必加
--compress，gzip 压缩能减少 60%+ 体积，IO 总量下降后，实际耗时常比不压缩还短
Access denied for SELECT INTO OUTFILE 报错怎么破？
这是最常卡住的点：mydumper 底层依赖 SELECT INTO OUTFILE，但 MySQL 默认关闭该能力：
- 检查
secure_file_priv值：SELECT @@secure_file_priv;，若返回NULL或空字符串，说明禁用，必须重启 MySQL 并配置secure_file_priv = /data/backup/mydumper_bak - 确认目标目录属主是
mysql用户且有写权限：chown mysql:mysql /data/backup/mydumper_bak - 备份用户必须有
FILE权限：GRANT FILE ON *.* TO 'u_mydumper'@'%';（很多教程漏掉这一条） - 若实在无法启用
secure_file_priv，改用--no-schemas+--no-data分步调试，先验证连接和权限通路
大表备份时 metadata 不准或恢复失败怎么办？
mydumper 对非事务表（MyISAM）、视图、存储过程不保证原子性，容易导致 GTID/binary log 位点偏移或外键冲突：
- 备份前加
--skip-tz-utc，避免每条INSERT都带CONVERT_TZ()，小表也提速 20% - 跨库依赖对象（如视图引用其他库表）必须手动导出结构：
mysqldump -d -n -t --skip-triggers db1 view_name > view.sql - 恢复时若报
Cannot add or update a child row，说明外键约束未关：myloader前先执行SET FOREIGN_KEY_CHECKS=0;（它本身不自动处理） -
metadata文件里记录的是备份开始时刻的 binlog pos，不是结束时刻——如果备份耗时长（>5 分钟），这个位置已滞后，做 PITR 时得结合SHOW MASTER STATUS手动校准
myloader 恢复慢或静默失败的真实原因
myloader 不是“一键还原”，它并行导入但不做事务合并，出错易被忽略：
- 默认不打印 SQL 错误，加
-v 3才能看到具体哪条语句失败 - 目标库字符集若与源库不一致（如源 utf8mb4，目标 latin1），
myloader会跳过整张表且无提示，务必提前CREATE DATABASE ... CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 自增 ID 冲突常见于重复恢复：用
--overwrite-tables替代手动删表，它会自动DROP+CREATE - 恢复大库时，
innodb_buffer_pool_size小于数据总量会导致频繁刷盘，建议调至物理内存的 70%
真正把 mydumper 用出效果，关键不在参数堆叠，而在理解它每一步在做什么——比如 FLUSH TABLES WITH READ LOCK 只锁几毫秒，但后续所有 dump 线程都靠事务快照读，这才是并发安全的底层逻辑。没看清这点，调再多线程也只是在等锁释放。
