mydumper 能显著加速大库导出，前提是表结构合理且 I/O 与网络不瓶颈；它通过多线程并发 dump 表（支持表内分块）远超 mysqldump 单线程性能，尤其适用于上百张表、超 100GB 场景。

mydumper 能不能真正加速大库导出

能，但前提是表结构合理、磁盘 I/O 和网络不成为瓶颈。它靠多线程并发 dump 表（甚至表内分块），比 mysqldump 单线程快数倍——尤其是有上百张表、总数据量超 100GB 的场景。

常见错误现象：mydumper 启动后只跑一两个线程、CPU 利用率低、导出速度没提升。这往往不是工具问题，而是默认参数太保守或 MySQL 侧限制了并发。

• 必须显式指定 -t（线程数），默认是 4，对大库通常不够；建议从 -t 8 或 -t 16 起调，观察 SHOW PROCESSLIST 中活跃连接数是否匹配
• MySQL 的 max_connections 得留足余量，mydumper 每个线程建一个连接，-t 16 就要至少 20+ 连接空闲
• 如果表含大量 BLOB/TEXT 字段，开启 --skip-tz-utc 和 --compress 反而可能拖慢，因为压缩耗 CPU，而磁盘或网络未必是瓶颈

导出时为什么某些表被跳过或报错 “Table doesn’t exist”

不是表真丢了，而是 mydumper 在初始扫描阶段读取 INFORMATION_SCHEMA.TABLES 后，后续 dump 时该表已被 DDL 修改（比如被 DROP 或 RENAME），导致一致性视图失效。

使用场景：线上边导出边做表结构变更，或定时任务和运维操作未错开。

• 加 --no-schemas 不能解决这个问题，它只跳过建表语句生成，不解决元数据快照问题
• 真正有效的是 --snapshot-all（需 MySQL 5.6+ 且开启 binlog），它会先获取一个全局一致的 GTID 或 binlog position，再导出，确保所有线程看到同一时刻的表状态
• 若 MySQL 版本旧或未开 binlog，只能靠业务低峰期操作 + --lock-all-tables（会加全局读锁，影响写入）

mydumper 导出的文件怎么还原？不要想当然用 source

mydumper 输出是多个 .sql（建表）和 .csv（数据）文件，混在一起用 source 会报错，因为 source 不认识 CSV 格式，也不处理文件依赖顺序。

正确做法是用配套的 myloader，它专为这些文件设计，能自动识别 schema / data 文件、并行导入、按依赖顺序执行。

• myloader -d /path/to/dump -t 8 -u user -p pass -h host 是最简命令，-t 建议和 dump 时一致
• 如果目标库已有同名表，myloader 默认会报错退出，加 --overwrite-tables 才会先 DROP
• 注意字符集：若 dump 时源库用 utf8mb4，但 myloader 连接参数没指定 --default-character-set=utf8mb4，可能触发乱码或报错

大库导出失败卡在 “Writing file xxx.csv” 怎么定位

这不是网络或权限问题，90% 是磁盘满、inode 耗尽，或者单表数据量过大导致临时内存溢出（mydumper 默认每 1000 行 flush 一次，但大字段会让单次 buffer 超限）。

性能影响：一旦卡住，整个线程阻塞，其他线程也可能因锁等待或连接堆积而变慢。

• 先查磁盘：df -h 和 df -i，尤其注意 /tmp（mydumper 默认用它缓存 CSV）
• 用 --chunk-filesize=50（单位 MB）强制分块，避免单文件过大；配合 --rows（如 --rows 50000）控制每块行数，比纯大小更稳定
• 如果某张表特别大（比如日志表），可单独用 --tables-list 排除它，后续用 SELECT ... INTO OUTFILE 手动处理

实际中最容易被忽略的，是 mydumper 对 MySQL 的 wait_timeout 敏感——导出耗时超过该值，连接会被服务端断开，但工具不一定立刻报错，而是卡住或静默失败。检查并临时调高它，比反复重试更省时间。