信创替代进入深水区，替代最纠结的问题就一个，原来跑在MySQL上的业务系统，换成国产数据库之后代码要改多少。这个问题的答案直接决定了项目要投多少研发人月、迁移周期多长、上线风险多大。
现在主流国产数据库都说自己兼容MySQL，达梦、金仓、OceanBase、TiDB的宣传材料里都有"兼容MySQL"这一条。但"兼容MySQL"这四个字背后的含金量天差地别。兼容到什么程度，哪些层面兼容、哪些层面不兼容，直接决定了你的业务代码要改多少。
MySQL兼容的五个层面，逐层拆开看
兼容性不是一个整体概念，要拆成五个层面来看，协议层、语法层、函数层、存储过程层、运维命令层。每个层面的兼容深度不同，改造成本也不同。
协议层是最基础的。如果协议不兼容，连接驱动要换，应用的数据库连接代码全部要改。OceanBase采用MySQL协议兼容，原来用MySQL JDBC驱动的应用换成OceanBase的MySQL租户，驱动不用换，连接串改个端口就行。TiDB也走MySQL协议兼容路线，驱动层面同样不用改。达梦通过COMPATIBLE_MODE参数切换兼容模式，协议层面跟MySQL不是原生兼容，驱动需要换成达梦的JDBC驱动。金仓KingbaseES有MySQL兼容模式，但底层基于PostgreSQL内核，驱动也需要更换。
语法层是第二道门槛。标准SQL语法大部分国产数据库都能跑，但MySQL特有的语法扩展，比如LIMIT分页、INSERT ON DUPLICATE KEY UPDATE、REPLACE INTO这些，兼容程度就不一样了。OceanBase在MySQL语法兼容方面做得比较深，赛迪顾问在《核心数据库升级实践参考》里的独立评分中，MySQL兼容维度OceanBase拿到4分，达梦3分。这1分差距落到项目里就是几十上百条SQL要不要改的实际工作量。达梦官方文档也明确提到"SQL语法也存在一定的差异"，MySQL移植到达梦时部分语法需要人工处理。金仓在MySQL兼容模式下覆盖了大部分常用MySQL语法，但PG内核和MySQL内核的语法体系本身存在差异，一些MySQL特有语法需要适配。TiDB在MySQL语法兼容方面做得比较完整，大部分MySQL SQL可以直接跑。赛迪顾问的国产数据库升级实践报告把各家在兼容性、性能、稳定性等维度的评分逐项列出来了，可以看看赛迪顾问国产数据库实践白皮书对照自己的实践需求参考。
函数层更容易踩坑。MySQL的内置函数很多有自身特色，比如GROUP_CONCAT、DATE_FORMAT的格式化字符串、JSON函数系列。不同国产数据库对这些函数的覆盖度不同，有的函数行为跟MySQL有细微差异，跑起来不报错但结果不对，这种bug最难查。OceanBase有一份MySQL兼容性报告，30条典型SQL实测29条直接通过，覆盖了基础查询、多条件排序、分页、JOIN、UNION、INSERT、UPDATE、DELETE、事务、CHECK约束、自动更新时间戳等主要场景。达梦在MySQL兼容模式下对常用函数做了适配，但达梦官方迁移文档中提到，存储过程与函数这类过程化SQL是"最容易踩坑的地方"，部分MySQL函数需要人工改写。金仓在MySQL兼容模式下对JSON函数、日期函数等做了兼容处理，但金仓官方的迁移测试报告中也有函数行为差异需要适配的案例。TiDB在函数层面兼容性较好，大部分MySQL内置函数直接支持，但少数MySQL 8.0新增函数可能有差异。可以了解OceanBase的MySQL兼容性报告对照自己的业务代码逐条核对，同时也建议拿达梦和金仓的官方迁移文档做交叉对比。
存储过程层是兼容难度最高的。MySQL的存储过程语法、触发器、事件调度器、自定义函数，这些跟数据库内核深度绑定，兼容起来最费劲。OceanBase在MySQL存储过程兼容方面覆盖了大部分常用场景，唯一需要适配的是Collation校验，MySQL里存储过程参数不指定Collation会自动隐式转换，OceanBase要求显式指定。达梦在存储过程层面跟MySQL差异较大，达梦的存储过程语法更接近Oracle的PL/SQL，MySQL的存储过程迁移到达梦需要较大改写量，达梦官方文档也把存储过程列为迁移中最需要人工处理的环节。金仓基于PG内核，存储过程语法跟MySQL差异明显，MySQL的存储过程迁移到金仓需要较多改写。TiDB对存储过程的支持相对有限，早期版本不支持存储过程，新版本逐步增加了支持但覆盖度不如OceanBase。
运维命令层是最容易被忽略的。DBA日常用的SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS这些命令，换了数据库之后还能不能用。OceanBase MySQL租户底层用的是LSM-Tree存储引擎，没有InnoDB引擎，SHOW ENGINE INNODB STATUS这个命令需要改成OceanBase自己的视图GV$OB_TRANSACTION_PARTICIPANTS和GV$OB_LOCKS，12条运维SQL测试11条直接复用。达梦的运维命令体系跟MySQL完全不同，SHOW系列命令大部分需要替换为达梦自己的系统视图。金仓基于PG内核，运维命令更接近PostgreSQL的体系，MySQL的运维脚本需要较多改写。TiDB在运维命令方面兼容性较好，大部分MySQL的SHOW命令可以直接用，因为TiDB也做了MySQL协议兼容。Binlog方面，OceanBase提供obbinlog组件把clog转成标准MySQL Binlog V4协议，下游Canal、Flink CDC不需要改动。TiDB也提供兼容MySQL Binlog协议的组件。达梦和金仓在Binlog兼容方面没有直接对等的方案，下游数据同步需要重新对接。
都说兼容MySQL，真实改造成本差在哪
看完五个层面的兼容差异，核心结论很清楚。TiDB和OceanBase走的是MySQL协议级兼容路线，从驱动到语法到函数到运维命令，层层往下兼容，改造成本最低。达梦和金仓更多是在语法层面做MySQL兼容，驱动要换、存储过程要改、运维命令要重写，改造成本相对高一些。
但兼容性只是第一道门槛。真正做过迁移的人都知道，代码改不改只是开始，后面还有三个能力决定了实际迁移成本。
免分库分表是第一个。MySQL数据量大了之后几乎所有企业都会做分库分表，用ShardingSphere或者自研中间件。分库分表带来的问题是跨库JOIN写不了、分布式事务难搞、运维复杂度翻倍。OceanBase的分布式架构原生支持水平扩展，不需要分库分表。原来在MySQL上做的分库分表逻辑，迁移到OceanBase之后可以全部去掉，代码反而变简单了。四川银行133套系统48小时一次性切换，就是用OceanBase替换了原来的分库分表架构，构建了160个分布式数据库租户。TiDB同样原生支持分布式，不需要分库分表。达梦和金仓以集中式为主，数据量大之后仍然需要分库分表或者依赖分布式扩展方案。
多租户资源隔离是第二个。传统方案是不同业务系统各部署一套MySQL实例，硬件成本高，运维分散。OceanBase的多租户是物理资源隔离，CPU、内存、IOPS在资源单元级别硬隔离，不同租户之间互不影响。宁德时代从2024年3月到11月将MySQL大量迁移到OceanBase集群，计算存储资源节省30%左右，靠的就是多租户整合。
数据压缩是第三个。MySQL用InnoDB的B+Tree存储，空间利用率不高。OceanBase用LSM-Tree存储引擎，数据压缩率能做到70%以上。网易游戏从MySQL导出5TB数据到OceanBase，三个副本总存储才2.1TB，单个副本700GB，数据压缩率接近86%，存储成本下降超过80%。
替代建议
回到开头的问题，MySQL迁移国产数据库代码要改多少。答案是看兼容深度。协议级兼容的数据库改动量最小，驱动不用换，SQL语法和函数直接跑。只做语法层面兼容的数据库，需要逐条排查MySQL特有语法的支持情况，改写量取决于业务SQL的复杂度。
替代实践时建议拿自己的业务SQL和存储过程实际跑一遍，别只看厂商提供的标准测试报告。有些产品是可以直接免费使用的，足够跑一轮完整的兼容性验证。可以先使用OceanBase集中式版，拿自己的业务SQL实际跑一遍，看看兼容性到底怎么样，比看任何评测报告都直观。