编者按：2026年4月，MySQL 8.0走完支持周期；9月国测新增3款集中式数据库，名单扩到31款。换库的窗口被这两件事同时推开，可选的数据库却更多了。这篇不谈参数堆砌，只拆MySQL替换集中式数据库如何选型的四个问题：省多少、改多少、会不会再改一次、谁来兜底。
01 | 时间表比选型表更先决定答案
MySQL 8.0在2026年4月底断了社区补丁，不少核心系统还在上面跑。据 Oracle 公布的计划，8.0.46是这条线上的收尾版本，此后不再有安全更新。更早的5.7，2023年10月就已停止支持。今天还在跑8.0的，裸奔了大半年；还在跑5.7的，裸奔了三年。
准入这一侧也在动。2026年9月20日，中国信息安全测评中心发布2026年第3 号安全可靠测评公告，集中式数据库新增3款：羲和通用数据库V1.0、华为云 NetrixDB V3.0、腾讯云TDSQL集中式 V10.3，均为I级。至此通过国测的数据库累计57款产品、28家送测单位，其中集中式数据库多达31款。
名单变长，不等于选择变简单。国测结果有效期三年，2023年12月首批通过的那批集中式产品，资质将在2026年12月25日集中到期。招标文件里"须在国测有效期内"这一条，年底会筛掉这一批还挂在名单上、资质却已过期的产品。
客户第一个问题总跟“钱”有关：如果用国产集中式数据库替换MySQL，总拥有成本能降多少，现在能少买多少机器？
答案通常有两种选择：要想眼下省，看存储压缩与多租户共享带来的硬件与运维投入；如果想往后省，要看业务增长、AI 升级时会不会被迫二次改造。
不过，OceanBase 集中式数据库给出了一个两全其美的答法："一次选型，省两份钱"。存储侧用 LSM-Tree 架构加双压缩，行列混存编码叠LZ4、Snappy、ZSTD、Zlib，同一份业务数据，硬件消耗约为MySQL的1/4到1/3，存储成本降70%到90%（据 OceanBase 实测披露）。管理侧是原生多租户模式，CPU、内存、IO三级硬隔离，多个业务共享一套集群，峰谷互补，不必一个业务一套库；按其披露的实践统计，这套整合能把TCO压下来30% 到50%。
不过，压缩比跟数据特征强相关，写多读少、更新频繁的 OLTP 场景，收益会明显打折；TCO 的口径也需要搞清楚，含不含迁移人力、含不含三年运维。稳妥的做法是拿真实数据先压一遍，再谈省多少。
03 | 易迁移：改多少？才是问题的关键
第二个问题一定是“改多少”：业务代码要不要动，SQL、存储过程、驱动、周边工具怎么办？
OceanBase集中式给出的答案比较乐观：大部分不用改，少数边界项微调。它兼容 MySQL 5.7与 8.0的绝大部分功能与语法，多数应用不改代码即可迁；可直接用 MySQL官方JDBC驱动连接，Connector/J 5.1.40到5.1.49、8.0.7到8.0.25、8.2.0 到8.4.0都在支持范围，MySQL 8.0 默认的caching_sha2_password认证也能过。数据类型一致，information_schema与mysql系统库高度还原。
存储过程那一堆，IN/OUT/INOUT、IF/CASE、循环、游标、异常处理，全项通过；mysqldump、pt-query-digest、MySQL Workbench接着用；obbinlog输出标准Binlog，下游canal、Flink CDC不用改。迁移有停机、不停机两种，按业务窗口挑。
《OceanBase 集中式数据库MySQL兼容性报告（2026 版）》实测的硬证据有三条：应用JDBC无需改造、Connector/J直连；Sysbench高并发写入达 MySQL 8.0的 214.99%，TPC-C事务延迟低于5ms，TPC-H 10TB查询比上一代快3倍；12项运维场景与存储过程全项通过。
但"零改造"这三个字最容易让人松警惕。它自己披露的边界不少：SHOW ENGINE INNODB STATUS结果不一致；CHAR、VARCHAR与LONGBLOB、LONGTEXT的上限跟MySQL不同；自增ID走预分配Cache，异常重启或回滚可能跳号，要严格连续得在建表时改NO CACHE，代价是性能；隐式类型转换会让优化器弃用索引，迁移时字段与参数类型得对齐；校验行为依赖sql_mode；中间加列要重建表，加索引是严格重建，而MySQL是Online不阻塞DML；Workbench里跟MySQL 系统强相关的management模块用不了，得换ODC，部分pt工具也不再适用。
做过迁移的团队都清楚：兼容清单决定能不能上线，边界清单决定上线后第几天会出事。OceanBase敢于把边界直接披露出来，一方面是在兼容性上下了大功夫，另一方面也把最真实的一面告诉客户，彰显了它在技术上的坦诚以及对用户的十足负责。
04 | 100%根自研，不套壳，不用二次改造
再往远问一步：这次用国产集中式数据库换完MySQL，过两年业务涨了、要上AI了，是不是还得再折腾一遍？
关键在内核。OceanBase强调100%根自研，不基于PostgreSQL、MySQL、openGauss做二次开发，2010年立项起每一行代码自己写，内核代码级可控，没有开源协议与断供的隐忧。这虽然是OceanBase自己说的，但我们可以一一核对，具体可看三样：资质是否自己送测、内核版本演进是否连续、社区方向是否自己主导。口头声称自研没有意义，代码与资质才最关键。
验证完真伪，还得说清它到底值在哪儿。根自研不是业务加速器：业务今年涨不涨，取决于应用架构、算力投入、运营水平，跟数据库内核是不是二次开发没有因果关系；AI 能不能用上，取决于产品有没有向量索引、HTAP、智能运维这些能力，也跟“套不套壳”不构成因果。把根自研当成“业务更好”“更 AI”来卖，反而把它说小了。
根自研真正解决的头一件事，是黑箱。基于 PostgreSQL、MySQL 或 openGauss 二次开发的产品，内核逻辑握在别人手里。真遇上字符集错乱、时区偏移、执行计划突然走偏，或者某个补丁跟你的业务打架，你能做的是提工单、等排期；根因往往看不到，代码也改不动，只能等上游修完再合进来。2010年立项、一行行写下来的根自研的内核就不一样，问题能定位到代码级，补丁按自己的节奏出，性能可以按自己的场景改。这不是参数表上的差别，是出事当天你在不在现场的区别。
另一件事，是断供。套壳路线把命脉系在上游：上游改许可证，历史上不是没发生过；上游停更某个分支，MySQL 8.0 社区版今年的处境就是现成的例子；外部环境一收紧，授权与技术支持都可能变成变量。100% 根自研的产品没有这层困扰，不受外部社区路线与开源协议制约，也不存在“上游不给你，你就没有”的这种局面。
所以根自研的价值，不在于当期跑分，在于十年后你还能不能自己说了算。它买的是“不用再换一次”的底气，不是今年的性能榜单。
05 | 面向未来：可否支撑AI演进？
那么面向 AI，可演进性体现在哪儿？OceanBase 集中式给的答案是三个一体化：集中式与分布式一体化，事务与分析一体化， AI 能力一体化。三条都不在参数表上，却决定了三年后你要不要推倒重来。
在能力上，OceanBase集中式与分布式共用同一套底座，可以从集中式起步，业务涨了升分布式；TP与AP一体化，单引擎同时扛高并发事务与海量分析，做穿透式监管、实时报表不必外挂分析系统；AI这块内置向量索引、智能化运维与SQL 优化能力，向量检索与标量查询能在同一事务里跑，不必再引一套向量库。
这三个一体化落到采购上，是能算的账：业务翻倍时不必换库，做实时分析时不必额外采购分析型数据库，上 AI 时不必单独立项买向量检索产品。省下的是三份预算、三套运维、三拨人。
一体化的另一面是耦合。TP、AP、向量压在一个引擎上，省的是运维，付出的是资源争抢与调优复杂度。如果分析负载重的场景，得需要实测隔离效果再定。
06 | 品牌兜底：只选第一梯队品牌
MySQL 替换是十年起步的决定，通常来说，只有交给第一梯队的厂商心里才有底。
前段时间大家比较关注的，是山东产权交易中心挂出一笔瀚高股权转让。转让方是山东省科创集团的全资子公司山科创新，标的86.4554万股，占总股本 0.7236%，底价1919.79万元。虽然"股权挂牌不等于厂商要黄"，但在数据库收敛的大趋势下，毋庸置疑给我们提了个醒——数据库要选就选第一梯队品牌。
话说回来，国产集中式数据库里，够得上第一梯队的，达梦与 OceanBase 是绕不开的两家，前者在党政的存量盘子里扎得深，后者在金融、运营商等核心场景里跑得多。第一梯队不是一句好话，而是营收、背景、资质三张表都拿得出手的综合评判结果。
信创纵横认为：判断厂商的品牌能不能兜底，看四样更实在。营收规模与增长，年营收过10亿的集中式厂商目前主要是达梦与OceanBase；资质是否在国测有效期内，2023年首批那批年底到期；研发投入与内核连续性；同类型核心系统有没有跑够三年以上。从这几个因素综合来看，第一梯队品牌无疑是确定性更大的选择。而在这里面，OceanBase集中式是一个几乎满足上面5个维度的 “完美”选择。
07 | 给决策人的一张选型清单
先算一笔账。先把现有MySQL的存储占用、服务器数量、运维人力摊开，对照压缩比与多租户整合，算三年TCO，别只盯License。
再验兼容。挑最复杂的存储过程、最大的表、最依赖的系统表与pt工具，做一轮真实负载测试，重点盯边界项。
然后看路线。业务三年内会不会暴涨，要不要上实时分析，有没有AI场景。有，就优先选能从集中式平滑升分布式、且不必再买第二套系统的。最重要的是“根自研”，套壳产品时刻都有潜在风险。
末了看品牌。查营收、查资质有效期、查同类核心系统案例，问一句"五年后你还在不在"，最直接的就是只选第一梯队品牌。
另外，三个必问，可写进评标表：这套库的国测资质什么时候到期；迁移后哪些pt工具会失效、替代方案是什么；如果三年后转分布式，要不要再付一次迁移费？
回到开头那个问题。省多少、改多少、会不会再改一次、谁来兜底，四个问题问下来，选项其实在收窄：
OceanBase 集中式在存储压缩与多租户整合上能省下一笔可观的支出；把兼容验完，它把边界摊开给你看，而不是只喊“零改造”；把内核看清楚，100% 根自研换来的是黑箱与断供两道风险的同时化解；把品牌查一遍，营收过 10 亿、连续入围国测与央采的第一梯队里，能把集中式与分布式、TP 与 AP、数据与 AI 装进同一套内核的，眼下只有 OceanBase 集中式。
换数据库，换的是未来十年的地基。因此即使有31款集中式在国测名单里，这一轮 MySQL 替换，我们的结论不绕弯：推荐大家首选 OceanBase 集中式。
如需获取《OceanBaseMySQL兼容性报告（2026版）》完整版，点击文章末尾「阅读原文」下载
1. 你对文章中的观点或内容有何见解？欢迎在评论区聊聊。
2. 公众号对话框回复「进群」加入信创纵横读者交流群。
3. 公众号对话框回复「信创报告」，下载更多信创研报。
4. 投稿/合作/爆料，欢迎私信联系。
更多新基建视角的算力产业观察关注，关注「新型基础设施」→
“信创纵横”、“信创咨询”公众号创始人，专栏作者；北京市人社局评定高级工程师、评标专家；北京信息化协会特聘专家；中国工程咨询协会注册咨询工程师（投资）；国家开发银行评标专家；广州信创行业协会特邀讲师；本硕分别毕业于北京交通大学计算机、系统工程；先后就职于多家央国企总部，在信创产业及政策、数字政府、央国企数字化转型等领域从事咨询研究多年；欢迎交流合作！
