mydumper 默认单线程，需显式指定 --threads 才启用并行；搭配 --chunk-filesize 才能真正分片导出；--no-locks 或 --use-savepoints 可减少锁影响；务必统一字符集并校验备份完整性。
mydumper 备份慢，是不是没开多线程？
默认情况下 mydumper 是单线程导出的，哪怕机器有 32 核，它也只用 1 个。这不是 bug，是设计如此——必须显式指定线程数才能启用并行。
- 关键参数是
--threads，比如--threads=8启用 8 个导出线程 - 注意：线程数不是越多越好，超过物理 CPU 核心数（或略高于）后收益急剧下降，还可能因 I/O 或锁争用拖慢整体速度
- 搭配
--chunk-filesize（如--chunk-filesize=64）可让大表自动分片，配合多线程真正起效；否则即使开了 8 线程，一张 200GB 的表仍由一个线程扛着 - 别漏掉
--skip-tz-utc，否则每个连接都会执行SET TIME_ZONE = '+00:00'，高并发下可能触发 MySQL 元数据锁等待
备份时主库卡顿，是不是 mydumper 锁表了？
mydumper 默认使用 START TRANSACTION WITH CONSISTENT SNAPSHOT，对 InnoDB 表不锁表，但会拉长事务视图，导致 purge 线程滞后、undo 日志膨胀、甚至 Waiting for table metadata lock 在 DDL 操作多的实例上频繁出现。
- 加
--no-locks可跳过全局读锁（仅适用于全 InnoDB），但要求所有表无 DDL、且能接受极短时间内的非严格一致性 - 更稳妥的是用
--use-savepoints，在长事务中设保存点，降低单次锁持有时间 - 避免在业务高峰跑全库备份；若必须，用
--long-query-guard=30和--kill-long-queries防止备份本身变成慢查询源 - 记得关掉
--lock-all-tables（默认不启用），这个一开就是全局 FTWRL，生产环境等同于停服
备份文件太多太碎，恢复时怎么对应？
mydumper 按表+chunk 分文件，schema.table.0000x.sql 这种命名看着自由，实际恢复时容易漏 chunk 或错顺序，尤其跨多个磁盘路径时。
- 务必用
--outputdir指定单一绝对路径，避免相对路径引发权限或挂载点识别问题 - 恢复前先跑
myloader --directory <code>/path/to/backup--query="SELECT 1" 测试目录结构是否可读，比直接恢复更早暴露权限/编码/文件损坏问题 - 不要手动拼接 SQL 文件执行；
myloader自动按schema.create.sql→schema.table-schema.sql→schema.table.00001.sql顺序加载，乱序会导致外键失败 - 如果用了
--compress，恢复时myloader必须带--compress，否则报Invalid archive header
备份完发现某张表丢了，或者字符集乱码？
常见原因不是 mydumper 本身坏了，而是连接层或服务端配置没对齐，尤其跨版本或跨地域部署时。
- 强制指定连接字符集：
--default-character-set=utf8mb4，否则可能退化成 latin1，导致 emoji 或中文写入乱码 - 检查 MySQL 服务端
character_set_server和collation_server，和客户端参数不一致时，mydumper会按服务端默认值建库建表，但导出内容按连接字符集编码，错位就丢数据 - 用
--verbose=3跑一次测试备份，看日志里有没有Warning: Skipping table xxx (no rows)或Could not get table list for db.xxx—— 很可能是账号没SELECT权限，或被sql_mode=STRICT_TRANS_TABLES拦截了某些字段类型 - 备份完成后立刻校验：
find /backup/path -name "*.sql" | xargs ls -l | wc -l对比表数量，再挑几张大表用head -20看开头是否有CREATE TABLE和正确字段定义
线程数、锁策略、目录结构、字符集——这四个点没对齐，再多核也是白搭。尤其是 --threads 和 --chunk-filesize 必须配对用，单独调一个基本没效果。
