mydumper 比 mysqldump 快因其默认按表并行导出、支持大表分 chunk(基于主键或自增列),而 mysqldump 为单线程且全表锁;实操需注意锁策略、并发数、chunk 大小、空目录及 schema 导出。

mydumper 导出时为什么比 mysqldump 快
因为 mydumper 默认按表并行导出,还能拆分大表为多个 chunk(基于主键或自增列),每个 chunk 单独写入文件;而 mysqldump 是单线程、全表锁(除非加 --single-transaction)、无法切片。
实操建议:
- 导出前确认源库有全局读锁能力(
FLUSH TABLES WITH READ LOCK)或启用--no-locks+--single-transaction(仅适用 InnoDB) - 用
--threads=8控制并发数,别盲目设太高——超过 CPU 核心数后 I/O 和锁争用反而拖慢 - 大表导出务必加
--chunk-filesize=64(单位 MB),避免单个 SQL 文件过大导致导入失败或内存溢出 - 导出目录必须为空,
mydumper不会覆盖同名文件,而是直接报错Directory not empty
myloader 导入时报错 “Unknown database” 或 “Table doesn’t exist”
这是路径或元数据不匹配的典型表现:不是数据丢了,是 myloader 没找到对应 schema 或没执行建库建表语句。
实操建议:
- 确保导出时用了
--compress就得用--compress-protocol导入,否则协议不匹配会静默跳过部分文件 - 导入前手动创建目标库:
CREATE DATABASE IF NOT EXISTS,target_dbmyloader默认不自动建库 - 检查导出目录下是否有
metadata文件和target_db.create.sql—— 如果没有,说明导出时漏了--schema参数 - 导入命令必须指定库名:
myloader --directory=./dump --database=target_db --threads=8,不能只写路径
跨服务器迁移时网络中断或导入卡住怎么续传
mydumper/myloader 本身不支持断点续传,但可以通过文件粒度+状态标记来模拟。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
实操建议:
- 导出用
--outputdir指定绝对路径,并记录最后完成的表名(看metadata文件里的Finished dump at:时间戳) - 导入前先
ls -1 ./dump/*.sql | grep -v "\.create\.sql" | wc -l统计总表数,再用mysql -e "SHOW TABLES IN target_db"查已存在表,差集即为待补表 - 对未完成的表,单独用
myloader --database=target_db --table=xxx --directory=./dump补导,注意加--overwrite-tables(否则跳过) - 别依赖
--resume—— 这是旧版 mydumper 的实验性参数,新版已移除,文档里也明确写了 “not reliable”
导入后数据量对不上,count(*) 差几万行
常见于含 TEXT/BLOB 字段的表,或字符集转换异常(比如源库是 utf8mb4,目标库默认 latin1),导致部分行写入失败但无报错。
实操建议:
- 导入后立刻查
myloader输出末尾的 summary 行,重点关注Loaded data和Skipped tables数字,不是所有跳过都会打 warning - 对比源/目标库的
information_schema.TABLES中TABLE_ROWS—— 这个值不准,改用SELECT COUNT(*) FROM table_name实测 - 开
--verbose=3重新导入一次,捕获日志里类似Query failed (1366): Incorrect string value的错误 - 目标库初始化时就指定字符集:
CREATE DATABASE target_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci
真正麻烦的是外键约束和触发器——它们不会被 mydumper 自动禁用,导入中途失败可能导致部分表数据写入、部分没写,且没回滚。动手前先 SET FOREIGN_KEY_CHECKS=0 和 SET SQL_LOG_BIN=0,这些得在导入前手动执行。










