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

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

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

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

## 一、MySQL迁移到底难在哪

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

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

## 二、5款工具，挨个说说

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

| 工具 | 适用场景 | 增量同步 | 数据校验 | 学习成本 | 数据量上限 | 跨库迁移 |
|------|---------|---------|---------|---------|-----------|---------|
| mysqldump | 小库备份、同版本迁移 | 不支持 | 手动对比 | 低 | 中小（<50GB） | 不支持 |
| DataX | 离线批量同步 | 不支持（需配Canal） | 有内置校验 | 中 | 大 | 支持 |
| Navicat | 临时迁移、小规模操作 | 不支持 | 无 | 极低 | 小（<10GB） | 支持 |
| **KDTS+KFS+KDC** | **信创迁移、异构同步** | **支持** | **自动化校验（KDC）** | **中** | **大** | **支持** |
| gh-ost | 在线DDL变更 | 不适用 | 有行数校验 | 高 | — | 不支持 |

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

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

```bash
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）。

```json
{
  "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迁移工具？遇到过什么坑？欢迎评论区聊聊，说不定你的经验能帮到其他人 👇

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


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

MySQL迁移工具实测对比：mysqldump/DataX/KFS选型指南与避坑实践

实测对比mysqldump、DataX、Navicat、KFS、gh-ost五款MySQL迁移工具，从适用场景、增量同步、学习成本等维度帮你选型，附4个实战避坑经验。

数据库

架构设计

职业发展

MySQL迁移工具实战经验分享，对比mysqldump、DataX、Navicat、KFS等5款工具优缺点。重点解析大表迁移、增量同步、数据校验等核心难点，提供信创迁移场景下的解决方案。包含字符集统一、存储过程迁移等4个常见坑点及规避方法，帮助开发者高效完成数据库迁移。

腾讯云数据库特惠，新用户首单0.5折起


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL迁移工具实测对比：mysqldump/DataX/KFS选型指南与避坑实践-腾讯云开发者社区-腾讯云

MySQL迁移工具实测对比：mysqldump/DataX/KFS选型指南与避坑实践

MySQL迁移工具实测对比：mysqldump/DataX/KFS选型指南与避坑实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐