是的，mydumper 多线程导出对大库（>50GB）和千万级单表提速3–8倍，但小库优势不明显；需注意版本兼容性、权限、线程配置及恢复时的参数调优。
mysqldump 备份慢，是不是该换 mydumper？
是的，mysqldump 单线程导出大库（尤其 >50GB）时，CPU 利用率低、I/O 串行，备份时间常被拉长到数小时。而 mydumper 原生支持多线程：按表、按 chunk 并行导出，实测对千万级以上单表提速 3–8 倍。
注意它不兼容 MySQL 8.0+ 的某些新权限模型（比如 APPLICATION_PASSWORD_ADMIN），部署前先确认版本：
mydumper --version建议用 0.11.1+，并确保用户有
SELECT、LOCK TABLES、RELOAD 权限。
-
mydumper默认按表分线程，大宽表（>200 列）或含大量 BLOB 字段时，可加--chunk-filesize=64启用行级分片 - 避免用
--regex过滤表名时写错正则（如漏转义点号），会导致跳过整库，建议先用--dry-run预览 - 导出目录必须为空，否则会报
Directory not empty错误，不是警告
恢复时为什么 myloader 还是卡在单线程？
因为默认不启用并行导入——即使你用了 mydumper 多线程导出，myloader 仍按顺序执行 SQL 文件。必须显式指定线程数：
myloader -d ./backup/ -t 8 -u root -p pass
-t 值不是越大越好：超过 CPU 核心数 × 2 后，磁盘 I/O 和 InnoDB buffer pool 竞争反而拖慢整体速度。常见坑是忽略 innodb_buffer_pool_size 配置，导致频繁刷脏页，恢复耗时翻倍。
- 恢复前务必关闭
innodb_flush_log_at_trx_commit=2和sync_binlog=0（仅限恢复期间） - 若目标库已存在同名表，
myloader不会自动DROP，需提前清理或加--overwrite-tables - 遇到
ERROR 1062: Duplicate entry，大概率是导出时没加--no-locks或锁表失败，导致部分数据重复写入
备份文件太多，怎么快速定位某张表的 SQL？
mydumper 按表拆成多个 .sql 文件（如 db.table1.00000.sql），但大表还会被切片。直接 ls 找不到，得靠命名规律和元数据文件。
关键看 metadata 文件里记录的 Started dump at: 时间戳，再结合 schema.table.sql 和 schema.table.00001.sql 编号判断分片逻辑。不要手动改文件名，myloader 依赖原始命名解析依赖关系。
- 搜索某张表：用
find ./backup -name "db\.table\.*\.sql"（注意反斜杠转义点号） - 想跳过某张大日志表？导出时用
--regex="^(?!(db\.log_))"，别用--ignore-table，后者不支持正则且易拼错库名 - 备份目录下
gtid_executed文件只在开启 GTID 时生成，恢复时myloader会自动读取并设置SET GLOBAL gtid_purged
用 mydumper 就一定比 mysqldump 快？
不一定。小库（mysqldump 的所有特性，比如 --tab 导出为文本、--xml 格式、或直接压缩到远程 pipe。
真正影响备份时长的，往往是锁等待和 binlog 写入竞争。如果你的业务无法接受 FLUSH TABLES WITH READ LOCK，就得考虑 --no-locks + --use-savepoints 组合，但这要求引擎为 InnoDB 且 binlog_format=ROW。
- 主从架构下，优先在从库备份，避免锁主库；但要注意
mydumper默认不识别从库角色，需手动加--skip-tz-utc避免时区转换错误 - 如果备份过程中出现
Lost connection to MySQL server during query，大概率是wait_timeout太短，调高到 600 秒再试 - 跨版本恢复（如 5.7 → 8.0）要小心
mysql系统库结构差异，myloader不做兼容性检查，直接报语法错误
多线程只是手段，真正省时间的前提是：锁得快、写得快、读得快。别光盯着工具参数，先看 SHOW PROCESSLIST 里卡在哪一步。
