mydumper 导出更快因支持按表并行与大表分片，而 mysqldump 为单线程；但需权衡并发压力、权限、GTID 及对象导出完整性，并合理调参线程数、分片粒度与IO配置。
mydumper 导出比 mysqldump 快在哪
根本区别在并发模型：mysqldump 是单线程逐表 dump，而 mydumper 默认按表并行（可配到 4–16 线程），还能对大表自动分片（--chunk-filesize 或 --rows），把一张千万级表拆成多个 SQL 文件并发导出。
但注意：并行不是无代价的。它会显著增加 MySQL 的读压力，可能触发 Too many connections 或锁等待；如果用的是 MyISAM，还会因表级锁导致实际并发度归零。
-
mydumper需要SELECT、LOCK TABLES、RELOAD权限，缺任意一个都会静默跳过表或报错Access denied - 不支持 GTID 自动识别，跨主从备份时得手动加
--no-locks --no-binlog避免一致性风险 - 默认不导出存储过程/函数/事件，要加
--triggers --routines --events才全
怎么调参让 mydumper 真正跑满 CPU 和磁盘
默认 --threads=4 往往不够——尤其当磁盘是 NVMe 或备份机有 16 核时。但盲目拉高线程数反而会让 IO 拥塞，建议按「磁盘队列深度」调：SSD 上 --threads=8–12，机械盘上别超 4。
真正影响速度的是分片粒度。对单表 >5GB 的场景，必须启用行级分片：
- 用
--rows=1000000比--chunk-filesize=256M更可控（后者受字符集和字段长度影响大） - 配合
--skip-tz-utc省掉每次连接都执行SET TIME_ZONE的开销 - 禁用压缩（
--compress）——CPU 压缩常比磁盘写还慢，除非网络带宽是瓶颈
示例命令：
mydumper --host=localhost --user=bkuser --password=*** --database=prod_db --threads=8 --rows=500000 --outputdir=/backup/mydumper_202405 --compress --build-empty-files
备份中途失败，怎么续传不重来
mydumper 本身不支持断点续传，但它的输出结构天然适配“找缺失再补”。关键看 --outputdir 下的文件命名规律：db.table.00001.sql.gz、db.table-schema.sql。
失败后先检查日志末尾的 Thread X failed 提示，再进输出目录用 ls -l | grep table | wc -l 对比预期分片数。缺失的序号就是待补范围。
- 用
--regex='^db\.table$'单独重跑那张表（注意加--overwrite-tables） - 若只缺某几个分片，可临时改源码或用
mydumper --where="id > 5000000"手动切片补 - 千万别直接删整个目录重跑——
mydumper不会校验已有文件，重复导出会多出 .00001.00001.sql 这类冲突名
还原时容易卡在某个大表的 LOAD DATA
myloader 默认也是多线程，但还原速度常被单个 LOAD DATA INFILE 拖垮——尤其当目标 MySQL 的 innodb_buffer_pool_size 不足，或 max_allowed_packet 小于单个分片 SQL 文件大小时。
常见症状是 myloader 日志停在某张表不动，SHOW PROCESSLIST 显示状态为 Writing to net 或 Updating 卡住十几分钟。
- 还原前务必设大缓冲：
SET GLOBAL innodb_buffer_pool_size = '12G';（按物理内存 70% 配） - 调高
max_allowed_packet到512M，否则分片文件解压后超限直接报错Packets larger than max_allowed_packet - 对超大表（>100GB），用
myloader --disable-binlog --queries-per-transaction=50000减少事务体积，避免 undo log 膨胀
最易忽略的一点：还原目录里如果有 .sql 和 .sql.gz 混存，myloader 会优先选未压缩版——但如果你只导出了 gzip 版，它就找不到文件，静默跳过。确认用 file db.table.00001.sql* 看清实际格式。
