去年底我们给一套 MySQL 系统搬了家。业务库跑两年，两千多张表，几十个存储过程，MySQL 5.7 一直扛着。搬去的地方是 KingbaseES。组里拢共三个人：我、开发小周、临时借来的运维老王。回头总结，我印象最深的不是数据怎么搬的，而是一开始差点用错工具------小周张口就是：用 MySQL 数据库管理工具导一下不就完了？
后来事情当然没那么简单。这篇按当时的顺序把过程捋一遍，每一步用了什么家什，踩了什么坑。工具能力部分以《KDMS 用户手册》为准，实践部分是我们自己的账单。
一、先想明白一件事：管理工具替代不了迁移工具
小周说的"导一下"，指的是拿图形化的 MySQL 管理工具把库结构和数据挪过去。听起来顺，做起来坑全在后面。
导数据确实不难，难的是搞清楚"迁过去之后还能不能用"。管理工具看到的是表和数据，看不到的是兼容性------几百个对象的定义里，哪些 KES 直接认，哪些要改，改多大。这些问题决定工期和预算。两千多张表翻一遍，人先累趴，更别提肉眼判断兼容度本来就是玄学。MySQL 那堆方言特性也让人头疼：CHARSET 声明、utf8mb4、空间索引、反引号、ON UPDATE 时间戳，平时看一点问题没有，搬家时全是要命的小零件。
我们以前就吃过抽样的亏。上一个项目评估期，请了位老师傅抽五十个存储过程逐条看。老师傅看得挺细，结论是"基本能迁"。结果真迁起来，剩下没抽到的四百多个里，藏着二十多个在 KES 上跑不了的。那回返工返得我肉疼。抽样抽得再认真，没抽到的部分就是黑洞。所以这轮我坚持全量：两千多张表一张不落，全采全评，黑洞不存在。
所以工具链的搭配是：管理工具继续管它的日常，搬家这一步交给 KDMS（金仓数据库迁移评估系统）。产品说明书里它的定位很清楚：基于"云+端+服务"架构，一键操作把迁移评估和转换跑完，支持 MySQL、Oracle、SQL Server、DB2 等主流源库。干的活三件：从源库采结构和 SQL、对着目标 KES 版本做兼容评估、把不兼容的对象转换改写。说明书里还给了个数据，转换速度每分钟 20 万行以上 SQL/PLSQL 代码。这个量级，人工敲键盘敲不出来。
二、采集：先把 MySQL 家底盘清楚
搬家第一步是清点家产。KDMS 的采集客户端连上 MySQL，把表、视图、触发器、约束、序列、函数、存储过程这些对象的结构信息收拢一遍。手册里写得很明确：只采结构，不碰业务数据，清点过程对生产库几乎零打扰。系统库也提醒了要排除------mysql、information_schema、performance_schema 跟业务无关，采进去反而添乱。
采集范围上，手册列的清单挺全，业务里常见的对象类型都在里面。我们的库结构杂，触发器二十多个，存储过程四十多个，一次采完，目录页里数量对得上，这事就放心了。
采集账号先备好。手册第四章给了 MySQL 的建号脚本，原文照抄：
sql
CREATE USER '采集账号'@'host' IDENTIFIED BY '采集密码';
GRANT ALL ON *.* TO '采集账号'@'host';
flush privileges;我们第一遍采的时候就栽了。账号建好连不上，报 CLIENT_PLUGIN_AUTH is required------MySQL 8 之后认证插件默认变了，手册第七章常见问题里正好收着这个坑：把认证方式改回 mysql_native_password，再给 root 补上 system_user 权限。第二个坑是编码，源库字符集要是 latin1，连接直接报 Latin is not supported，手册给的解法是先把 MySQL 侧统一成 UTF-8 再采。我们那库正好是 latin1，当时改了半宿。这两个坑踩完，小周说了一句：这手册第七章简直是为我们写的。
结构采完还差一半：应用实际发的 SQL。这部分走动态采集，MySQL 侧的办法是打开 general_log，把日志输出定向到表里：
sql
SET GLOBAL general_log = ON;
SET GLOBAL LOG_OUTPUT = 'TABLE';
-- 之后查看抓取结果
select * from mysql.general_log order by event_time desc;开一段、抓一段、记得关。我们挑了个凌晨，抓了三小时，怕日志把生产库拖慢，老王一直盯着连接数。最后拿到的，是上线后真实负载里的 SQL，比从代码里翻全得多------那套系统源码本来就不全。手册还支持离线材料：MyBatis 的 Mapper xml 打 zip、现成的 sql 文件、Java 程序运行的 jar，都能喂进去。顺带说一句，同样是动态采集，Oracle 源库走的是 v$sqlarea，带执行次数和最近活跃时间；MySQL 这个 general_log 法子是手册里最朴素、最好上手的一种。
离线采集我们其实也用过一回。另一个项目是老的 MyBatis 项目，源码和 xml 都齐，直接按手册把 Mapper 的 xml 打成 zip 传上去，SQL 扫描结果就出来了，比在运行环境里蹲日志省事得多。xml、sql 文件、jar 这三种离线材料，按项目手里有什么挑着用就行。
采集完产出一个 zip 包（200MB 以内），传到评估管理页面，新建评估，选目标 KES 版本，点确定，剩下的交给系统跑。这个上传弹窗手册里截图交代得清楚：只能传 zip、大小上限 200MB，传上去之后源数据库和兼容模式会自动识别填充，人真正要做的，就是选个目标版本、起个评估名称。剩下就是泡杯茶等状态栏从"分析中"走到"完成"。泡茶这事别小看，老王为此专门买了罐新茶叶。 
三、评估：MySQL 特有的坑，提前全掀出来
评估报告出来那天，我盯着兼容度一栏看了很久。
评估列表页本身就是一张总表：每个评估项目一行，评估名称、类型、源库、目标 KES 版本、评估时间、有效对象数、兼容数、不兼容数、兼容度，全列在上面。单位里三套系统排迁移先后，我把它们全跑了一遍评估，排成一列横向一比，哪套迁得动、哪套费劲，一眼就出来。后来给领导汇报排期，用的就是这张表，领导没再追问过一句"依据呢"。
手册里有个 MySQL 示例项目（MySQL-20250418-144246），评估概要的汇总条是这么写的：兼容 77、不兼容 14、手动调整 0、总计 91，兼容度 84.62%。我拿这个数字跟领导汇报，领导没吭声，指着"不兼容 14"问：14 个都要重写？我没直接答，把页面往下滚了一层。底下那张不兼容清单，才是有信息量的地方------每个不兼容对象都挂着具体原因，还按原因聚合、按数量降序排。
清单里的报错信息特别有 MySQL 味。有的表卡在 CHARSET 声明上，报 extraneous input 'CHARSET'；有的语句里带着 utf8mb4 字样，解析直接挂；还有 mismatch input '=' expecting 'ON' 的。最典型的是一个空间索引 spatldx 的建表语句，语法树里没有它的位置。这堆东西，用管理工具一百年也看不出来------表在那儿好好的，数据也能查，组里开发谁也没想到，一个从没出过问题的建表语句，换个库就成了硬伤。
这些报错翻译成人话，就是 MySQL 特有语法和 KES 语法树之间的缝隙。CHARSET 声明和 utf8mb4 是字符集相关，建表语句里多出来的那几行，KES 不认；spatldx 那个是空间索引，MySQL 支持，KES 没有对应的语法位置；'=' expecting 'ON' 那类，多半是触发器或约束写法上的出入。每一条不兼容背后，都是一句明确的原因，不是"大概有问题"。
最妙的还是聚合视图，小周先发现的。有一类报错，点开一看，底下躺着三张表：t_sold_order、test_date、test_string，共 3 条。三个对象不兼容，根子是一个问题------三张表用了同一个 KES 不认的写法。改一处，三条全清。"条数"和"问题数"差着一个数量级，排期按哪个算，结论完全不同。评估会上领导问改造量多少，我们把聚合清单往桌上一放：14 个对象，归并下来没那么多。
报告还有个容易被忽略的作用：它把"能用的"也数出来了。哪些表、哪些存储过程原样能跑，占比多少，全有数。人力投放就有了靶子------不兼容的那 14 个对象重点伺候，剩下 77 个过一遍验证就行。小周当时负责分活，照着这份报告排期，两周的排期一周半干完。
改造那几天，我们改一处验一处，保存后汇总条的兼容度当场重算。等把不兼容的清单销完，兼容度走满，那份 excel 就成了验收口径------逐条销项，一条不多一条不少，谁也别想糊弄过去。
四、转换与衔接：改完还能立刻验
评估把问题列清之后，改造环节不用导出导入来回倒。评估详情页里，每个不兼容对象都挂着原始语句和报错信息，点开编辑界面，左边是 MySQL 原文，右边手动调整，改完点校验，控制台立刻告诉你过没过。过了就保存，这条对象的评估结果翻成兼容，汇总条里的兼容度当场重算------改一条，账变一次，肉眼可见。
说明书里有句话我当时划了线：KDMS 的转换是"编程语言级的翻译"------解析源库 SQL 的语义，形成结构化逻辑对象，再按目标库语法和对等函数生成能跑的语句，不是字符串替换。我转述给老王听，他琢磨了半分钟，说：那就是会读句子的翻译，不是拿词典硬查词。话糙，理不糙。所以转换出来的东西大多不需要人再动，真正留给人工的，是那批解析都过不去的硬骨头。
都改利索了，交付物一次拿齐：评估报告一份 word，存在不兼容对象的额外出一份 excel 逐条记录；对象语句按类型导出------table、view、procedure、function、trigger、sequence、index，七个 .sql 文件，自动转换加手动修改的结果全在里面，拿去目标库直接建。过程中真碰上疑难，还能走工单找原厂 DBA 支持，这是"云+端+服务"里最实在的一块。结构迁移完，业务数据由配套的迁移环节承接，两边一合，割接就是安排好的事。
真正让我意外的是切过去之后的日子。迁到 KingbaseES，日常运维从 MySQL 那套工具切过来，习惯成本比想象小得多------KES 自带的命令行终端，交互方式跟 mysql 终端一个路数，查表、看结构、跑 SQL，肌肉记忆基本平移；要图形界面，配套的图形开发工具把对象浏览、SQL 编辑都罩住了。建表、改结构、跑查询这些日常操作，图形界面都齐活。小周从 MySQL 换过来，半天就把日常巡检跑顺了，下班前还发了条消息：这工具也不赖。老王更省事，命令行习惯几乎没改，上手那几天一个问题都没来问过我。后来聚餐他还感慨，说这次迁移是他干过最省心的一次。
收尾
回看这次搬家，体会就一条：先把账算清楚。两千多张表里到底几个"水土不服"，报告用一份 word 加一张 excel 说完了；哪些要改、怎么改、改完验不验得过，链路上每一步都有落点。
如果你手上也有一套 MySQL 在琢磨迁不迁，别自己翻库了。跑一次评估，报告出来那一刻，心里就有数。数据库这类事，我越来越信一句话：能用工具量出来的，就别靠人拍。管理工具、迁移工具、评估报告，各管一段；人只做工具盖不到的那一点点判断。