各位好，我是路远。
Oracle迁国产的活我干了不下二十个。大存储过程重写、序列改造、同义词替换，那套流程闭着眼都能走完。每次项目做完，光SQL改写文档就有上百页。
但MySQL迁国产，这还是头一回。
最近接了个MySQL迁KES的项目。客户是一家互联网公司，订单系统跑了六年MySQL，单表两亿多行。信创要求下来了，得换成国产数据库。
客户最担心的就一件事：迁移要改多少代码？这个问题直接决定了项目的工期和成本。
我之前做过一个Oracle迁国产的项目，光存储过程就改了两个月。客户听完直接问：MySQL迁移会不会也是这个量级？
我当时没法给准话。MySQL的生态和Oracle差别太大了。驱动体系、SQL方言、内置函数，每个环节都可能出问题。说实话，我自己心里也没底。
刚好KES最近发了新版本V9R3C18，重点就是MySQL兼容能力升级。我拿这个版本做了一轮验货。下面把四个特性的实测结果拆给各位看。
有好消息，也有踩坑的地方。各位耐心看完。
01 驱动层：MySQL原生驱动能直连，这一条很关键
迁移评估第一步，我一般先看驱动层。这决定了迁移的基本面。
如果目标数据库要求换驱动，那工作量就大了。一个中等规模的系统，几十个服务模块。每个都要改驱动依赖、重新编译、跑回归测试。光这一步可能就要两三周。
KES V9R3C18支持MySQL JDBC Driver 5.1.47及以下、MySQL ODBC Driver 5.3及以下直连。这意味着Java应用基本不用换驱动包。
我拿客户的Spring Boot项目试了一下。把连接地址改成目标库的地址和端口，其他不动。跑起来，基本的CRUD操作都正常。
这里有个细节要注意。JDBC Driver版本限制是5.1.47及以下。现在很多新项目用的是8.x的驱动。如果你们用的是高版本驱动，得降级或者做适配测试。这不是KES独有的问题，但迁移前必须确认。
# 原MySQL连接配置
spring.datasource.url=jdbc:mysql://10.0.1.100:3306/order_db
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
# 改为KES（仅改地址和端口）
spring.datasource.url=jdbc:mysql://10.0.1.200:54321/order_db
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
连接层不用改驱动。这一条能省掉整个迁移过程中大约15%~20%的工作量。
先给各位看一张对比表。Oracle迁国产和MySQL迁KES，改造量完全不是一个量级。
| 迁移维度 | Oracle → 国产 | MySQL → KES（V9R3C18） |
|---|---|---|
| 驱动层 | 需要替换驱动包，重新编译 | MySQL原生驱动直连，零改动 |
| SQL语法改造量 | 大，PL/SQL方言差异显著 | 小，1200条实测98%+直通 |
| 存储过程 | 重写为主，工期按月算 | 微调为主，30个里改5个 |
| 函数兼容 | 需大量改写或自建替代函数 | 高频函数1:1对齐 |
| 内置JSON支持 | Oracle无原生JSON类型，需额外方案 | JSON函数+虚拟列索引全兼容 |
| 预估工期（中型系统） | 2~3个月 | 2~3周 |
这张表说明一件事：MySQL迁KES的改造量，确实比Oracle迁国产小一个数量级。对互联网公司来说，这意味着可以按周而不是按月来排期。
02 SQL语法：99%对齐，剩下的1%是什么？
官方说法是"99%常用语法全对齐"。作为DBA，习惯先验一遍再说。99%意味着每100条SQL就有1条可能有问题。一个复杂系统几万条SQL，得逐条过心里才踏实。
实测下来，情况比我预期的好，但也有坑。
好消息是，DDL、DML、DQL这些基础语法，确实可以原样跑。我在KES测试环境跑了客户的核心SQL。大约1200条，1180多条直接通过。通过率大概98%出头。比我预期的要好。
剩下十几条有问题的，集中在存储过程和特殊函数调用上。
遇到问题的主要集中在几个方面：
存储过程的语法差异。 MySQL的存储过程用BEGIN…END包裹，里面可以DECLARE变量、用游标。目标数据库对这部分的兼容度在提升。但一些复杂的嵌套存储过程还是有语法差异。客户的系统有30多个存储过程，大概2个需要调整。
自定义函数的行为差异。 有些函数名相同，但参数类型或返回值的行为有细微差别。比如DATE_FORMAT函数。国产库兼容了大部分格式串，但MySQL特有的格式符可能不支持。
字符集和排序规则。 MySQL的utf8mb4是事实标准。迁移到国产库后，字符集处理要验证一遍。特别是emoji和特殊字符的存储，一定要单独测试。
-- 这条在KES上直接能跑
SELECT order_id, create_time, amount
FROM orders
WHERE create_time >= '2026-01-01'
ORDER BY amount DESC
LIMIT 100;
-- 但这种写法要注意，MySQL的某些隐式类型转换在KES上可能报错
SELECT * FROM orders WHERE order_id = '12345';
-- order_id是bigint类型，字符串比较在严格模式下会失败
说白了，99%是大面上的覆盖率。迁移前拿真实业务SQL跑一遍兼容性测试，这是标准流程，跟用哪个库没关系。
03 函数和JSON：业务逻辑层的兼容是真正的痛点
这一条比SQL语法更影响迁移成本。
为什么？因为SQL语法差异好发现——跑不通就报错。但函数行为差异很隐蔽。同样的函数调用，返回结果格式稍微不同。业务逻辑就不对了。而且这种问题往往要到UAT甚至生产环境才暴露。
KES新版本在字符串函数、格式化函数、转义函数上做了1:1对齐。我跑了CONCAT、SUBSTRING、REPLACE、FORMAT这些高频函数，输出结果和MySQL一致。
JSON部分是亮点。MySQL 5.7开始支持JSON类型和JSON函数。很多互联网公司的系统大量用了JSON字段。KES新版本对JSON函数和操作符优先级的兼容做得不错。JSON_EXTRACT、JSON_SET、JSON_ARRAY这些常用函数都能正常工作。
-- JSON查询正常执行
SELECT JSON_EXTRACT(extra_info, '$.payment_method') AS pay_method
FROM orders
WHERE order_id = 10001;
-- JSON更新
UPDATE orders
SET extra_info = JSON_SET(extra_info, '$.status', 'shipped')
WHERE order_id = 10001;
我特别测了一下JSON字段的索引效率。MySQL里可以对JSON字段建虚拟列索引。KES也支持了这个能力。查询性能和MySQL在同一量级。这对用了JSON做灵活schema的系统来说是个好消息。
不过有个提醒。JSON字段在MySQL里存储和索引的方式，跟传统关系型字段不一样。迁移后JSON字段的查询性能要单独压测。底层存储引擎变了，执行计划可能完全不同。
04 C API兼容：C/C++项目迁移的新选择
前面三个特性主要影响Java/Python等上层语言的项目。C API兼容针对的是C/C++直接调用MySQL客户端库的场景。
说实话，这个场景在互联网公司不多见。但在一些老系统、嵌入式场景里，C API还是很常见的。
KES新版本新增了MySQL C API完全兼容接口。C/C++业务代码理论上可以直接编译运行。主库自动识别、超时配置、自增ID获取都支持了。
这一条我没有条件做完整实测。客户那边没有C/C++的项目。但从接口定义来看，覆盖了mysql_real_connect、mysql_query、mysql_store_result这些核心API。
如果你的系统有C/C++组件直连MySQL的情况。这一条要重点关注。迁移前把API调用列表拉出来，逐个验证。尤其是字符集设置、连接超时、错误处理这些细节。
怎么判断你的系统改造量大不大？
做完这轮验货，我总结了一个简单的判断框架。各位可以对照自家系统，提前评估迁移成本。
改造量小的系统（大概率接近零改造）：
- 纯CRUD业务，没有存储过程
- 没用JSON字段，或者JSON只做存取不做复杂查询
- JDBC驱动版本在5.1.47及以下
- 没有C/C++组件直连数据库
这种系统换连接地址就能跑。我这次测的客户，如果只有订单表的增删改查，基本就是这个情况。
改造量中等的系统（需要1~2周适配）：
- 有存储过程，但逻辑简单，没有深层嵌套
- 用了JSON字段，且有虚拟列索引
- 有一些自定义函数，但都是标准写法
- 驱动版本偏高，需要降级测试
客户的订单系统属于这一类。30多个存储过程改了2个。两周内搞定，比预期快不少。
改造量较大的系统（需要认真规划）：
- 大量复杂存储过程，有多层嵌套和游标操作
- 深度依赖MySQL特有行为（隐式类型转换、非标准字符集处理）
- C/C++组件大量使用MySQL C API
- 用了MySQL的某些高级特性（分区表特殊语法、复制相关函数等）
这种系统建议先做一轮SQL审计，把风险点列出来，再定迁移计划。
说白了，改造量取决于你用了MySQL的多少"非标准"能力。用得越标准，迁移越顺。
零改造这事，验完之后我信了
各位可能注意到了，KES这次的关键词是"0改造迁移"。说实话，我一开始对这个说法是有保留的。干了这么多年数据库，任何两个库之间迁移，"零改造"三个字听着都太好了。
但这次验完，我的看法变了。
简单CRUD系统换连接地址就能跑，这个不用多说。让我意外的是，稍微复杂一点的系统——有存储过程、有JSON操作——改造量也很小。客户的订单系统30多个存储过程，最后只改了2个。
从Oracle迁国产，我习惯了动辄几个月的改写周期。MySQL迁KES完全不是一个量级。KES在驱动直连和函数对齐上做的工作，直接把迁移过程中最耗时的两道工序砍掉了。这不是概念包装，是实测出来的结果。
KES V9R3C18在MySQL兼容上到底做对了什么？
回顾这轮验货，我觉得KES这次升级抓到了MySQL迁移的几个真正痛点。
驱动直连省的不是技术复杂度，是工期。一个中等规模系统，几十个服务模块不用改驱动依赖，光这一项就能省两周。SQL和函数的对齐也到位，1200条核心SQL跑出98%+通过率，大部分业务代码可以直接搬。
JSON能力补齐这条我觉得最值钱。很多互联网公司的系统重度使用JSON，MySQL有原生JSON类型和函数，如果目标库不支持，迁移基本不可能。KES补齐了JSON函数+虚拟列索引，互联网场景的刚需算是堵上了。
C API兼容这个场景虽然少见，但说明KES的兼容思路是往下钻的。驱动层、SQL层、API层全覆盖。不是只做表面文章。
跟几年前比，国产数据库在MySQL兼容上进步不小。KES V9R3C18是我目前测过的，MySQL兼容做得最完整的一个版本。
迁移前的检查清单
结合这次验货踩过的坑，给各位列一个MySQL迁移的检查清单。建议迁移前逐条过一遍。
驱动层：
- 确认当前使用的JDBC/ODBC驱动版本
- JDBC Driver是否在5.1.47及以下，高版本需要降级测试
- 连接池配置（HikariCP、Druid等）是否需要调整
SQL层：
- 拉取生产环境的慢查询日志和全量SQL日志
- 在目标库上跑一遍兼容性测试，重点关注DDL和复杂查询
- 存储过程和自定义函数逐个验证
- 隐式类型转换的写法要排查
函数和数据类型：
- JSON字段的存储和查询行为要单独测试
- 日期时间函数的格式串差异要确认
- 字符集和排序规则要验证，特别是emoji场景
- 自增ID的行为是否一致
性能层：
- 核心业务SQL的执行计划在新环境上跑一遍
- 高并发场景压测，关注连接池行为和锁机制差异
- JSON字段的索引效率要验证
回退方案：
- 数据回流方案必须提前准备好
- 灰度切换策略要明确
- 切换后第一时间把监控告警接上——我之前有一次切完库就忙别的去了，结果当天下午出了个慢查询，等业务方反馈才发现。要是监控提前配好，五分钟就能处理
做了这么多年数据库迁移，兼容性做得再好，迁移前的验证工作也不能省。这是铁律。
从Oracle迁国产，我们习惯了"大改一场"的心理准备。MySQL迁KES可以换个思路——改造量确实比Oracle小一个数量级。驱动直连省掉换包工序，SQL和函数对齐压低改写量，JSON能力补齐互联网刚需。KES V9R3C18在MySQL兼容上做的这些事，大部分MySQL系统迁过来，改造量都不会太大。
零改造归零改造，迁移前的验证还是要跑。发现一个问题在测试环境解决，成本是1。带到生产环境再解决，成本可能就是100。
提前做好验证，心里才有底。
各位做过MySQL迁移到国产库的吗？遇到了哪些兼容性问题？评论区聊聊，互相少踩点坑。
我是路远，咱们下篇见。
