从mysqldump到Clone：MySQL数据迁移的六种方式与避坑指南

做MySQL数据迁移，最容易犯的第一个错误，是把“导出导入”和“数据迁移”当成一回事。其实前者只是手段，后者要考虑停机窗口、数据量、版本差异、增量数据、字符集、存储过程、权限账号甚至部署环境。我见过不少同事在项目里把同一套mysqldump命令复制到所有场景，小的库倒没什么，几百万行数据的库也敢在业务高峰期硬导，结果字符集乱码、触发器丢失、时间差八小时、大表锁死、恢复一半报错，来来回回折腾一整夜。

今天这篇我打算把MySQL常见的数据迁移方式真正捋一遍：逻辑导入导出、文本文件搬运、并行导出工具、物理文件迁移、Clone克隆、增量同步这几种路线都会讲清楚，重点放在每种方式的适用边界和实际操作中容易踩的坑。适合需要跨环境同步数据的开发者、负责数据库运维的同学，以及正在准备MySQL面试、想系统补这块知识的人参考。

1. 动手前先分清“逻辑迁移 / 物理迁移 / 同步复制”三个方向

接到一个“把MySQL从A迁到B”的需求，别急着敲命令。第一件事是判断这个迁移属于哪一类，因为类别选错了，后面所有努力都可能白费。

我把日常场景按方向拆成三类。

第一类是逻辑迁移。mysqldump导出SQL、再导入目标库，属于逻辑迁移；SELECT INTO OUTFILE导出CSV、再LOAD DATA导入也属于逻辑迁移。逻辑迁移拿到的是建表语句和插入语句，本质上和“人肉拷贝数据”差不多，和源库的物理文件格式、版本细节关系不大。所以跨小版本迁移、跨平台迁移、云上云下迁移，逻辑迁移往往是最稳妥的起点。

第二类是物理迁移。直接把整个数据目录复制到新机器，或者用XtraBackup做物理备份恢复，属于物理迁移。这种方法速度快，不需要经过SQL解析和索引重建，但它和MySQL版本、操作系统、数据字典格式强相关。比如MySQL 5.7的数据目录直接扔给8.0去启动，绝大多数情况是起不来的。

第三类是同步复制迁移。目标实例作为源实例的从库，持续追binlog，追平后切换，属于同步复制迁移。它解决的痛点是“停机窗口不够”。如果只允许你停十分钟，但业务每秒钟都在写入，前面两种方式导完的快照已经是过去式了，必须靠同步复制把增量补上。

针对不同需求，选型大致可以这么看：

你可能会觉得这些分类有点“教科书”，但实际决策时特别管用。有一次线上库要做版本升级，数据量不到100GB，结果有人直接准备用tar打包数据目录去新环境。幸亏提前确认了新版本是8.0，而源库还是5.7，物理目录根本无法兼容，临时改成mysqldump加停机升级方案，才没有把迁移窗口拖到不可控。

2. mysqldump：中小库和日常导入导出最实用的命令组合

mysqldump是MySQL官方自带的逻辑备份工具，也是绝大多数人接触到的第一个迁移方案。它最大的优点是通用、可控、可读取，适合日常单库或多库迁移、备份归档、跨版本迁移前的数据导出。

2.1 一条能用于绝大多数场景的导出命令

如果做一次全库备份并且之后要恢复到独立实例，我通常用这种组合：

bash复制mysqldump -h 127.0.0.1 -u root -p \
  --single-transaction \
  --routines --events --triggers \
  --hex-blob \
  --set-gtid-purged=OFF \
  --databases db1 db2 \
  > /data/backup/db_$(date +%F).sql

这里有几个参数，每个都是经历过实际坑之后才加上去的。

--single-transaction 意味着InnoDB表通过一致性快照读取数据，导出过程中不锁业务写操作。它利用的是REPEATABLE READ事务隔离级别。代价是导出期间如果有DDL操作，比如有人执行了ALTER TABLE，DDL会隐式提交事务，可能导致后续导出的表数据不在同一个时间点上。所以哪怕用了这个参数，也最好选择业务低峰期。

--routines --events --triggers 这个组合很多人会漏。触发器默认会跟着表一起导出，但存储过程、存储函数和事件调度器默认不会跟着走。你要迁移一个业务库，结果存储过程全没带过去，对应用来说可能直接就是一次事故。

--hex-blob 处理二进制字段。如果表里有BLOB、BINARY这类字段，不加它导出的数据很可能出现乱码或转义错误。

--set-gtid-purged=OFF 这个要看场景。如果源库开启了GTID，mysqldump导出的文件默认会带上SET GTID_PURGED语句。在普通独立迁移中，这条语句很容易和目标实例已有GTID状态冲突，导致导入报错。所以当目标实例只是普通环境、不打算建立复制关系时，我一般直接设成OFF；如果这份备份要用来搭建从库，就不要加OFF，保留GTID信息反而更好处理。

2.2 只导部分表或部分数据怎样更省事

很多开发同学以为mysqldump只能导整库，其实单表和多表导出很简单：

bash复制# 导出某个库中的指定两张表
mysqldump -h 127.0.0.1 -uroot -p \
  --single-transaction \
  dbname table1 table2 \
  > /data/backup/tables.sql

# 只导出满足条件的部分数据
mysqldump -h 127.0.0.1 -uroot -p \
  --single-transaction \
  dbname table1 \
  --where="create_time >= '2025-01-01'" \
  > /data/backup/table1_part.sql

只导出表结构时用--no-data，只导出数据不要建表语句时用--no-create-info。如果想把部分历史表排除掉，mysqldump没有直接的exclude参数，可以用--ignore-table=dbname.log_table，但要注意数据库名和表名的大小写必须和实际一致，否则会“假装忽略成功”实际仍然导出了。

恢复就简单了，两种方式等价：

bash复制mysql -h 127.0.0.1 -uroot -p --default-character-set=utf8mb4 < /data/backup/db.sql

sql复制-- 进入mysql命令行后执行
source /data/backup/db.sql;

如果备份文件很大，建议导出时先压缩，避免网络传输时白白浪费带宽：

bash复制mysqldump ... | gzip > /data/backup/db.sql.gz
gzip -dc /data/backup/db.sql.gz | mysql -h 127.0.0.1 -uroot -p ...

2.3 mysqldump恢复时的常见报错和应急思路

遇到过好几次ERROR 2006: MySQL server has gone away，原因是备份文件里有很大的行数据，目标实例的max_allowed_packet设置偏小。导入之前先在目标实例检查这个参数，如果不够就临时调大再恢复：

sql复制SET GLOBAL max_allowed_packet = 1073741824;

这里有个容易被忽略的细节：max_allowed_packet是会话级和全局级同时存在的参数。你只改全局，当前已有的连接不生效，mysql命令行要重新连接一次再执行source。

另外一个常见报错和sql_mode有关。MySQL 8.0默认启用了STRICT_TRANS_TABLES等严格模式，如果源库5.7时代的数据里存在非法日期、超过字段长度的字符串，恢复时就会直接报错。紧急处理时可以把目标库的sql_mode调成兼容模式，恢复完成后再改回标准值。但根本上还是要确认业务数据是否真的有问题，别为了导入成功掩盖了数据质量问题。

mysqldump还有个很现实的局限：它是单线程导出，数据量越大耗时越长，而且生成的文件是逐条INSERT，恢复速度也不会快。中小库它是王者，几十G以上的大库就需要看后面的章节。

3. CSV/TXT 文件通道：适合异构数据库和超大表的那条路

另一种非常实用但常常被低看的迁移方式是“文本文件通道”：先通过SQL把数据导出成CSV或TSV，再通过LOAD DATA导入目标库。它最大的价值有两点，一是跨数据库类型，二是在处理超大表时比逐条INSERT快得多。

3.1 用SELECT INTO OUTFILE导文件

MySQL支持直接把查询结果写到服务器本地文件：

sql复制SELECT id, user_name, created_at
INTO OUTFILE '/var/lib/mysql-files/user_20250101.csv'
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM db_user
WHERE created_at >= '2025-01-01';

执行前有几个前提必须先确认。

第一，文件路径必须满足secure_file_priv限制。你可以先执行：

sql复制SHOW VARIABLES LIKE 'secure_file_priv';

如果结果是NULL，说明这个功能被禁止，你需要调整MySQL配置或者改用客户端工具导出。如果结果是一个目录路径，那么导出文件只能写到那个目录里。很多人在这一步直接报The MySQL server is running with the --secure-file-priv option so it cannot execute this statement，就是没先看这个变量。

第二，文件是写MySQL服务器本机，不是写你电脑上。所谓“服务器本机”有可能是数据库容器内部，不是宿主机。Docker部署的MySQL在执行这条SQL时，路径是容器里的路径，不是宿主机的路径。

3.2 LOAD DATA恢复的完整姿势

文件导好之后，恢复操作一般是：

sql复制LOAD DATA INFILE '/var/lib/mysql-files/user_20250101.csv'
INTO TABLE db_user
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(id, user_name, created_at);

如果你执行LOAD DATA时报权限问题，看看是不是需要LOCAL关键字和客户端参数。LOAD DATA LOCAL INFILE指的是文件在客户端机器上，要先把local_infile打开。MySQL 8.0以后出于安全考虑，很多发行版默认关闭了这个特性，需要同时配置服务端和客户端：

sql复制SET GLOBAL local_infile = 1;

然后重新连接客户端。注意LOCAL INFILE有安全风险，正常情况下别长期开启，用完关掉。

另一个容易搞混的点是NULL值。默认情况下，文本里的\N会被识别为NULL，而不是把空字符串当成NULL。如果你从其他数据库导出的文件里，空字段就真的是空白字符串，导入后NULL字段会变成空串，后面查询IS NULL就会漏数据。处理时可以用SET子句转换：

sql复制LOAD DATA INFILE '/tmp/user.csv'
INTO TABLE db_user
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
(id, user_name, created_at)
SET created_at = IF(created_at = '', NULL, created_at);

3.3 mysqlimport与批量导入提速经验

命令行场景可以使用mysqlimport，它是LOAD DATA的封装：

bash复制mysqlimport --local \
  --fields-terminated-by=',' \
  --fields-optionally-enclosed-by='"' \
  --lines-terminated-by='\n' \
  -u root -p dbname /data/user.csv

有一个坑必须说清楚：mysqlimport要求文件名去掉扩展名后和表名一致。也就是说user.csv默认导入的目标是user表。如果你要导入到db_user表，要么把文件改名为db_user.csv，要么干脆用mysql命令行执行LOAD DATA。

大批量导入的提速经验可以这么总结：

• 导入前把FOREIGN_KEY_CHECKS=0关掉，外键校验很消耗时间。
• 如果目标表有大量二级索引，可以先把非唯一索引删掉，数据加载完成后再统一建索引。唯一索引不能随便删，否则重复数据会悄悄进去。
• 尽量把autocommit关掉，让多行数据在一个事务内提交。但也不要把几千万行塞进一个事务，undo会膨胀得很厉害。比较合理的做法是分批提交，比如每几万行提交一次。
• LOAD DATA本身比逐条INSERT快很多，因为它减少了SQL解析、权限检查、批量行插入的开销。对几十万行到千万行级别的数据，这是性价比最高的方式。

4. 大库并行导出导入：mydumper、mysqlpump 与异构工具的取舍

遇到几百GB甚至上TB的库，mysqldump单线程特性会让迁移慢到怀疑人生。这时候并行逻辑工具就有价值了。

4.1 mysqlpump为什么没能成为默认答案

mysqlpump是MySQL官方推出的并行逻辑备份工具，设计目标就是替代mysqldump的一部分场景。它支持按线程并行备份，也支持压缩输出。但在实际使用中，mysqlpump的并行控制、备用一致性处理、DDL兼容性都有不少历史问题，在MySQL 8.0.34版本开始被官方标记为废弃，所以我不建议新项目再花精力构建在mysqlpump上。如果你的环境已经有MySQL 8.0.3x之前的版本并且用得好，那继续用没问题；但如果你是刚接触，直接学mydumper更实际。

4.2 mydumper/myloader：目前逻辑备份的并行主力

mydumper是一个开源并行逻辑备份工具，myloader是配套恢复工具。它的思路是把一个库拆成多个chunk，用多个线程同时导出，导出结果不是一个大SQL文件，而是一堆按表拆分的SQL文件和metadata信息。

典型用法：

bash复制# 并行导出库 db1
mydumper -u root -p '密码' -h 127.0.0.1 -B db1 \
  --threads=8 \
  --chunk-filesize=256 \
  --triggers --routines --events \
  -o /data/backup/db1_dump

# 并行导入到目标实例
myloader -u root -p '密码' -h 127.0.0.2 \
  -d /data/backup/db1_dump \
  --threads=8 \
  --queries-per-transaction=1000

--chunk-filesize=256不是指“每个表固定切成256MB”，而是让mydumper对单表按行数做动态切分，尽量让每个线程拿到大致均衡的数据量。--queries-per-transaction控制恢复时一个事务里打包多少条语句，值太小会频繁提交，值太大会让undo膨胀。

mydumper相对mysqldump的主要优势是速度快，特别是在多核服务器上，导出速度能提升好几倍。恢复端也一样，myloader多线程并行导入，比mysql单线程source快很多。

但mydumper也不是银弹。它生成的SQL文件对MySQL版本敏感，备份工具版本最好和源库版本匹配。不同版本的MySQL在数据类型、注释、权限内部表结构上有差异，工具版本太旧可能解析不了新版本的binlog或元数据。

4.3 异构迁移用DataX这一类同步框架

如果源库不是MySQL，比如要从Oracle、PostgreSQL、SQL Server迁移到MySQL，那单纯靠MySQL生态工具就不够用了。逻辑上通用做法是先导成CSV/TXT中间文件再LOAD DATA，但这需要自己处理字段类型映射、分页抽取、失败重试，太繁琐。

实际项目里用DataX这类同步框架的人比较多。DataX是阿里巴巴开源的数据同步工具，通过一个JSON配置文件描述reader插件和writer插件，就能在异构数据源之间搬运数据。用起来大约是三步：准备一个配置文件，声明从哪个数据源读、写到哪个目标端，然后执行python bin/datax.py job.json。

它和MySQL原生文本通道的区别在于，DataX自己完成了类型映射和分批读取，不需要你手工去处理CSV中的NULL、时间格式、外部键顺序这些问题。如果你的迁移不是一次性拷贝，而是希望后续能按主键增量同步，那更需要这类工具或直接考虑binlog同步方案。

5. 物理迁移和 Clone：嫌弃慢的人通常选这条路

逻辑导入导出面对大库时最大的痛点是速度。如果你有一个2TB的实例，用mysqldump导出可能要跑十几个小时，导入又要十几个小时，整个窗口几乎不可接受。这时物理备份恢复是更实际的选择。

5.1 XtraBackup的标准备份恢复流程

Percona XtraBackup是数据库领域物理备份最常用的工具，它能在MySQL运行时直接做物理备份，通过并行复制InnoDB数据文件、追加备份期间的redo日志，保证备份文件是一致的。版本选择上有个硬规则：Percona XtraBackup 2.4用于MySQL 5.7和5.6，Percona XtraBackup 8.0用于MySQL 8.0，别拿2.4去备份8.0。

完整流程是三步：

bash复制# 第一步：执行备份
xtrabackup --backup \
  --target-dir=/data/backup/full \
  --host=127.0.0.1 \
  --user=backuper \
  --password='密码'

# 第二步：准备备份，让数据文件达到一致状态
xtrabackup --prepare \
  --target-dir=/data/backup/full

# 第三步：新实例上恢复数据文件
xtrabackup --copy-back \
  --target-dir=/data/backup/full \
  --datadir=/var/lib/mysql

chown -R mysql:mysql /var/lib/mysql

第二步的prepare不能省。备份阶段复制出来的文件，相当于把硬盘上正在使用的数据页直接拷出来了，里面还包含一些尚未提交的事务和redo log状态。prepare会应用redo日志并回滚未完成事务，让数据文件变成真正一致的“已完成状态”。

有次我接手一个项目，同事直接从源实例的/var/lib/mysql目录打包拷到新机器，结果启动后报一大堆InnoDB错误，原因就是他没有先停库，文件根本不在一致状态。如果你一定要用“直接拷目录”这种冷备方案，前提必须是源实例已经干净停机，用systemctl stop mysqld或mysqladmin shutdown把进程停下来，然后再打包，否则问题会非常随机，有时候能起，有时候起不来，有时候重启后才发现丢了最近的事务。

准备跨实例恢复时还有几个细节要注意。一是新实例的server_uuid不能和源实例一样，否则在复制场景或者部分高可用组件里会冲突。修改方法很简单，删除或替换数据目录下的auto.cnf文件，让MySQL启动时重新生成。二是lower_case_table_names在两台机器上必须一致。Linux上默认是0，表名大小写敏感；Windows上默认是1，表名不敏感。如果你把Linux上的数据文件搬到一台改变了这个参数的机器上，经常会遇到表找不到的错误。

5.2 MySQL 8.0的Clone插件：另一种物理克隆

从MySQL 8.0.17开始，官方提供了Clone插件。它可以直接在运行中的实例上做本地或远程克隆。相比XtraBackup，它不需要额外安装第三方工具，权限和依赖关系也更干净。

远程Clone的典型过程是：

sql复制-- 在接收端实例执行，假设要从192.168.1.10的实例克隆数据
SET GLOBAL clone_valid_donor_list = '192.168.1.10:3306';

CLONE INSTANCE FROM 'clone_user'@'192.168.1.10' IDENTIFIED BY '密码';

执行远程Clone会直接覆盖接收端当前的数据目录，所以接收端在操作之前不要留有任何重要数据。克隆完成后，MySQL实例通常会自动重启。需要给源实例上的专用账号授予权限，典型是BACKUP_ADMIN，接收端账号需要CLONE_ADMIN权限。

Clone插件最大的应用价值是快速搭建和源实例一致的环境，比如秒级拉起测试库、作为复制从库的起点。它和XtraBackup不是竞争关系，而是官方在8.0里提供的原生选择。如果你已经上到8.0，而且不想折腾第三方工具，Clone会比XtraBackup省心不少。

5.3 物理迁移不是万能药

物理迁移虽然快，但跨版本的能力很差。MySQL 5.7和8.0的数据字典结构差异很大，8.0内部把元数据统一放进了数据字典表，还新增