MySQL数据迁移最佳实践：5款工具对比与信创场景选型策略

大家好，我是数据库小学妹 👋

前段时间接了个MySQL迁移到国产数据库的项目。领导给了一周，还补了一句：“数据不能丢，业务不能停。”

我心凉了半截。光评估市面上的工具就花了两天，最后还是踩了几个坑。好在上周项目终于做完了，今天把之前踩过的坑整理出来，希望能帮大家少走弯路少踩坑。

在展开之前，先帮不太熟悉的朋友理一下：MySQL迁移工具，简单说就是能把MySQL的表结构、数据、索引、存储过程这些对象，从一个库搬到另一个库的专用软件。常见的有mysqldump、DataX、Navicat、KFS（Kingbase FlySync）等，选的时候主要看三样：数据量多大、要不要增量同步、目标库是什么。

一、MySQL迁移到底难在哪

很多人以为数据迁移就是"导出来、再导进去"，实际上没那么简单。字段类型不匹配，导入直接报错。字符集没统一，中文变成乱码。最要命的是大表迁移过程中有新数据写入，源库和目标库的数据就对不上了。

选MySQL迁移工具，说白了就是选怎么扛住这些风险。

二、5款工具，挨个说说

市面上工具不少，我把反复用过和仔细对比过的5款挑出来，逐个聊聊。先看总览。

2.1 mysqldump：小库够用，大库别碰

MySQL自带的导出工具，用法很简单：

mysqldump -h 127.0.0.1 -u root -p --opt --default-character-set=utf8 mydb > /tmp/mydb.sql

导出SQL文件，再导入到目标库。5分钟上手，不用装别的东西。如果用的是InnoDB引擎，建议加--single-transaction参数，它会在导出前开启一个一致性快照，导出期间不锁表，业务照常读写。不加的话，导出过程中表会被锁住，写入全部阻塞。这个参数很多人不知道，但对线上库迁移来说是必须的。

但我第一次用它迁一个30GB的库，加了--single-transaction，导出还是花了40分钟，导入又花了一小时。它也不支持增量同步，导出之后新产生的数据丢了就是丢了。总的来说，库不大、允许停机、同版本MySQL之间迁移可以用它，超出这个范围就别勉强了。

2.2 DataX：批量搬运能手，但配置太累

阿里开源的离线同步框架，支持几十种数据源。从MySQL搬到MySQL行，搬到HDFS、Hive也行。

坑在哪？每张表要单独写一个JSON任务配置，结构大概是这样：reader部分指定MySQL连接和查询SQL，writer部分指定目标库的写入方式（insert/replace/upsert）。

{
  "reader": { "name": "mysqlreader", "parameter": { "connection": [{"jdbcUrl": ["jdbc:mysql://127.0.0.1:3306/src"], "table": ["user"]}], "username": "root", "password": "***" } },
  "writer": { "name": "mysqlwriter", "parameter": { "connection": [{"jdbcUrl": "jdbc:mysql://127.0.0.1:3307/dst", "table": ["user"]}], "username": "root", "password": "***", "writeMode": "replace" } }
}

200多张表就要写200多个这样的配置文件，光这项工作就花了一下午。而且它不支持增量，要增量同步得自己搭Canal解析binlog，运维成本翻倍。适合的场景是数据仓库之间的批量ETL，或者一次性的大规模搬迁，需要持续同步的信创迁移DataX搞不定。

2.3 Navicat：应急可以，别当生产工具

4步完成迁移：连源库、连目标库、选表、开传。连SQL都不用写，临时搬几张表或者给测试环境造数据的时候挺好用。

同事用它迁过一个8GB的库，传到一半报错，字段类型映射出了问题，没有断点续传只能重来。加上商业版要收费，应急偶尔用用还行，生产环境不太靠谱。

2.4 KFS：信创迁移场景下的首选

信创迁移到金仓数据库，通常不是单靠一个工具完成的，而是三个工具配合：KDTS负责全量迁移和结构转换，KFS负责增量实时同步，KDC负责数据校验。KFS全称是"金仓异构数据同步软件"（Kingbase FlySync），在方案里承担的是增量同步这一环。

用下来有几个点印象比较深。

全量迁移靠KDTS。它能自动识别并转换表结构、索引、视图、存储过程，不用一个个手动改字段类型映射。之前做异构迁移最头疼的就是这块，经常改到半夜。现在KDTS跑一遍，结构迁移基本就到位了。

增量同步是KFS的强项。基于binlog实时捕获，同步延迟在毫秒级别。迁移过程中源库有新写入也能同步过去，切业务的时候数据基本是实时一致的。之前那个项目领导要求"业务不停机"，靠的就是KFS这个能力。

数据校验是KDC的活。之前用mysqldump迁移，全量导完我得自己写SQL一条条比对，200多张表校验了一整天。配合KDC，迁移完成后自动逐表比对源库和目标库的数据一致性，有差异直接标出来。当时第一次跑校验，还真发现了几张表的字段精度有偏差，幸好在测试阶段就拦住了。

还有个可视化监控界面，迁移进度和数据流向一清二楚。哪张表同步延迟高了、哪条数据校验出差异了，界面上直接标红。领导喜欢看这个，我也省了不少解释的功夫。KFS还支持断点续传，迁移过程中网络抖了一下，恢复之后从断点继续，不用从头来。

之前团队评估过传统"导出-转换-导入"的方案，预估要48小时。换成KDTS加KFS的方案之后，全量加增量追平，实际不到4个小时。

2.5 gh-ost / pt-online-schema-change：改表结构用的

这俩不算迁移工具，是在线DDL变更工具。但讨论MySQL迁移经常被提到，顺带说一下。

gh-ost是GitHub开源的，思路和直接ALTER TABLE完全不同。直接ALTER是原地锁表修改，期间完全不可写。gh-ost的做法是：创建影子表，分批拷贝数据，用binlog实时追增量，数据追平后原子RENAME TABLE切换，全程原表可正常读写。

之前有个项目，8000万行的订单表要加字段，直接ALTER跑了40分钟还锁表，业务方电话打爆了。换gh-ost在线完成，业务基本无感知。

注意它只管"改表结构"，不管"搬数据"，跨库迁移帮不上忙。

三、怎么选？看三个点

选工具看什么？数据量多大、要不要增量同步、目标库是什么。库小、允许停机的，mysqldump或者Navicat就够用。数据量大、一次性搬完的，DataX批量能力强。要持续同步的信创迁移，KFS比较对路。同实例内改表结构，gh-ost。

这里多说一句。如果你在做MySQL到国产数据库的迁移，信创合规是硬要求，那选工具就不能图省事了。兼容性、增量同步、数据校验，三个都得过关。也有人选自己写脚本迁移，前期能跑通，但后面维护成本很高，表结构一改脚本就挂，排查问题也没有日志可看。工具方案的学习成本是一次性的，脚本方案的维护成本是持续的。

KES配合KDTS、KFS、KDC的组合，在信创迁移场景里落地比较早，案例也多。KES对MySQL的SQL语法兼容度比较高，应用层基本不用改代码。KDTS负责全量迁移和结构自动转换，KFS负责增量实时同步，KDC负责数据一致性校验，从迁移启动到业务切换，全链路都能覆盖。在金融、政务、制造这些行业里落地案例挺多的。我们团队当时也是参考了几个同行的案例才下的决定。

四、MySQL迁移工具实操中，我踩过的4个坑

只测全量不测增量。全量数据对上了就以为没问题了，结果上线后发现增量同步漏了好几条记录。后来在测试阶段就模拟写入操作，确认增量数据实时同步到目标库才放心。

字符集没统一。源库utf8mb4，目标库utf8，用户昵称里的emoji全变成问号。现在我迁移前第一件事就是查两端字符集。

大表一次性导出。50GB的表直接mysqldump，内存爆了。后来按主键范围切片，分批处理，稳多了。

漏了存储过程和触发器，这个坑踩得最深。当时以为mysqldump默认什么都导，结果上线后发现几个定时任务不跑了，排查了半天才意识到触发器根本没迁过来。mysqldump得手动加-R参数才导存储过程和触发器，DataX更干脆，存储过程迁移直接不支持。库里有这些东西，一定要单独处理，迁移完再逐个验证。

最后说两句

MySQL迁移工具没有"最好"这一说，看你的场景。小库应急mysqldump，批量搬DataX，信创场景KFS，各有各的活法。动手之前先想清楚三个事：数据量、停机窗口、目标库类型，想明白了选工具就不太会出大问题。

这里重点说下信创迁移场景。如果目标是KES，KDTS+KFS+KDC这套组合有三个比较突出的能力：全量+自动转换，KDTS将表结构、索引、存储过程自动迁移，不用手动改字段映射；实时同步，KFS基于binlog毫秒级增量捕获，迁移期间业务不用停；自动校验，KDC逐表比对一致性，有差异直接标出来。在金融和政务项目里落地比较多，我们团队当初也是看了同行案例才做的决定。

你用过哪几款MySQL迁移工具？遇到过什么坑？欢迎评论区聊聊，说不定你的经验能帮到其他人 👇

我是数据库小学妹，咱们下篇见 👋