ReaderMX.
四海内皆兄弟

MySQL 国产替换集中式怎么选？看这五个维度就够了

四薛晓刚约 9 分钟
数据库选型 · 实战观察
公司的 MySQL 要做国产化替换，到底该怎么选？问的人多了，我发现大家的困惑其实很集中——不是不知道有哪些产品，而是不知道该拿什么标准去比。看宣传材料，家家都说自己兼容 MySQL、性能强、自主可控；真到选型会上，又发现谁都说服不了谁。
我自己的习惯是把它拆成五个维度：省成本、易迁移、根自研、AI 能力、品牌兜底。这五个维度过一遍，基本上能筛掉大部分不合适的选项。今天就拿 OceanBase 集中式数据库为例，把这五个维度逐个拆开聊聊。
至于集中式和分布式到底各自适合什么场景，那是另一个话题，我们下一篇再展开。
维度 01
省成本，是真金白银还是账面好看
信创替换的 TCO（总拥有成本），是决策层最关心的指标。很多人第一反应是比硬件价格，但真正的成本黑洞其实在两个地方：存储和运维。
先说存储。
传统 MySQL 用的是行存架构，压缩率有限，数据量和历史表一多，磁盘很快成为瓶颈。我见过不止一个案例：业务量其实不大，但表多、历史数据多，三年下来存储成本翻了几倍。
OceanBase 的做法是基于 LSM-Tree 架构做高压缩。写入的数据先落到内存里的 MemTable，再异步刷盘形成 SSTable 文件，这个过程配合行列混存编码（Encoding）和多重压缩算法（LZ4 / Snappy / ZSTD），能拿到相当可观的压缩效率。
存储成本降低 70% ~ 90%
同等业务规模下，硬件消耗约为 MySQL 的 1/3 ~ 1/4
我拿过几个实际迁移案例的数据核对过，这个量级是可信的
再说运维。
传统模式下「一个业务一套库」是常态：每个系统独立部署、独立维护、独立备份，数据库实例数量随业务线性膨胀，运维人力也跟着膨胀。
OceanBase 的原生多租户能力可以把多个业务整合进同一套集中式集群。CPU、内存、IO 三级硬隔离，租户之间互不影响，但共享底层基础设施，按需分配、峰谷互补。直接结果是数据库实例数量大幅收敛，运维人力随之下降。
结合多个行业客户的实践统计，这套多租户资源整合方案能帮助企业 TCO 降低 30% 到 50%。
维度 02
易迁移，代码到底要改多少
先说一个前提：为什么大家都强调要兼容 MySQL？因为 MySQL 的生态在国内实在太大了。十几年下来，大量的业务系统、开发框架、运维工具、人员技能都是围绕它长出来的。不兼容，就等于主动放弃这块市场——客户不会为了一次信创替换，把整个应用重写一遍。
只有把兼容性做到位，才能把更多场景的数据库平迁过来；反过来，凡是要求应用重做的方案，代价都太大了。这一点在今天尤其现实：大部分用户的 IT 预算早已不像早年那样宽裕，已经没有太多预算可以支撑一次重做级别的改造了。
迁移成本是项目风险的核心变量。代码改造量越大，工期越长，上线后的稳定性风险越高。这个问题不靠宣传语回答，得看具体的兼容项清单。OceanBase 对 MySQL 的兼容性覆盖度，是目前同类产品中比较成熟的一档。我实际用 obclient 连过它的 MySQL 模式，从建表语法（AUTO_INCREMENT、VARCHAR、DECIMAL、TIMESTAMP）到日常 SQL，基本是原生的 MySQL 手感，这点体验很直接。具体来说：
▸ 应用程序可直接使用 MySQL 官方 JDBC 驱动（Connector/J 5.1.40～5.1.49、8.0.7～8.0.25、8.2.0～8.4.0），无需改造
▸ 数据类型（整数、定点、浮点、日期时间、ENUM、SET、JSON、空间类型）基本一致
▸ information_schema 与 mysql 系统库高度还原
▸ 12 项常用运维场景全部通过实测
▸ 存储过程（IN/OUT/INOUT 参数、变量、IF/CASE、LOOP/WHILE、游标、异常处理）全项通过
▸ mysqldump、pt-query-digest、MySQL Workbench 等 DBA 常用工具可延续使用
▸ obbinlog 输出标准 MySQL Binlog，下游 canal、Flink CDC 无需改造
我见过最理想的情况，是应用代码一行没改，驱动直连，迁移窗口一次切换完成。但这不是普遍情况——每家企业的 SQL 写法都有一些自己的习惯，边界项需要提前摸清楚。这里也要说一句公道话：敢把不兼容项主动列出来的厂商，反而更可信。OceanBase 官方的《MySQL 兼容性报告》里就明确写了几处差异，比如 SHOW ENGINE INNODB STATUS 结果不一致（它没用 InnoDB 引擎）、自增 ID 采用预分配 Cache 在异常重启时可能跳号、中间加列需要重建表等。这些建议在评估阶段全部跑一遍，把风险项在测试环境里消化掉。
熟悉我的人知道，聊兼容性时我通常还会多问一句：光语法兼容够不够？数据库的优化器，是不是也能给出同样的性能？
这才是兼容性的深水区。语法能跑通，不代表执行计划一样；执行计划不一样，性能就可能天差地别。尤其是那些跑了十几年的老系统，SQL 写得复杂，优化器行为一变，慢查询可能成片冒出来。
从我自己的实测和同行反馈看，OceanBase 在这块目前做得还可以，相对于不少数据库而言是更进一步的：For MySQL 版本在部分场景下甚至比原生 MySQL 还要好一点。对 MySQL 替换来说，这意味着不只是「能跑」，而是大概率「跑得不会差」。
维度 03
根自研，决定要不要做二次改造
这是我认为在信创选型中最容易被低估的一个维度，也是最容易埋雷的地方。
市面上不少国产数据库，骨子里是 MySQL 或 PostgreSQL 的分支，做了一些优化和定制，但底层内核不掌握在自己手里。好处是起步快、兼容性容易做；坏处是：当业务遇到内核级别的问题时，厂商有没有能力从底层代码层面解决？修一个 Bug 可能要等上游社区发版，主动权不在自己手里。
更麻烦的是合规问题——底层有开源依赖，就要受制于开源协议约束，存在法律风险和技术断供风险。这也是我常说的「二次信创改造」风险：选了一款内核不是自己的产品，短期能跑，但三五年后因为合规口径变化、技术路线受限，被迫再换一次。这个代价，比第一次迁移大得多。
OceanBase 的技术路线是从第一行代码开始完全自己写，2010 年立项，不基于 MySQL、不基于 PostgreSQL、不基于 openGauss，100% 根自研。这一点在其官网和技术文档中有明确说明，我也核验过它的研发历史和代码仓库。带来的实际意义是：内核代码级可控，遇到问题能从底层定位和修复，不依赖第三方社区；不存在开源协议风险，技术供应链自主安全。
这里再补一个可以自己验证的判断方法：OceanBase 是为数不多的、从存储引擎开始真正从 0 自研的数据库之一。
这件事不用听厂商说，去查各家公布的研发投入就一目了然——每年在数据库内核上投入多少研发资源，基本就决定了它是真自研还是拿开源改一改。研发投入的力度，同时也决定了产品的质量上限：内核是自己一行行写出来的，才谈得上对每一行代码的掌控，才谈得上在关键业务上出问题时的兜底能力。
对于金融核心、政务、能源这类对稳定性要求极高的场景，「根自研」三个字不是宣传口径，是实打实的风险兜底能力。
维度 04
能不能顺手把 AI 能力也带上
这两年大模型火起来，很多企业在做数据库选型时会多问一句：这套数据库未来能不能承接 AI 场景？要不要再单独上一套向量数据库？
这个问题很现实。如果数据库本身不支持向量和多模态检索，企业就得再引入一个独立组件，数据在两套系统之间来回搬迁，运维复杂度和权限管理成本陡增。
我用自己的环境实测过 OceanBase 的 AI 能力（4.5.0 版本，Docker 部署，MySQL 模式连接），几个关键能力是真实可用的：
顺带说一句，我写的这本书，用的恰好就是 OceanBase 兼容 MySQL 的集中式版本，书里涉及到的 AI 特性我一一做了验证，全部跑通——从分词、全文索引、向量检索，到完整的 RAG 知识库搭建与 Agent 会话记忆，都是真实环境里跑出来的结果，不是照着文档抄的。下面这几项，就是从那一章里摘出来的关键验证结论。
向量类型与检索
4.x 版本引入了 VECTOR(n) 数据类型，可以直接在建表时声明向量列，配合 L2 距离、余弦距离、内积等函数做语义相似度查询。我在商品表里加了一列 VECTOR(1024) 存商品语义向量，查询响应是毫秒级的。
全文检索
内置 Ngram 和 Space 两种分词器，中文场景用 Ngram。创建全文索引的方式也很 MySQL 化——CREATE FULLTEXT INDEX ... WITH PARSER ngram，然后用标准的 MATCH ... AGAINST 做关键词检索。对中文关键词的精确匹配，效果验证过是可靠的。
混合搜索与 RAG
这是我实测下来最有价值的一点。先用全文条件缩小候选集，再用向量距离精排，一套 SQL 里同时完成结构化过滤、关键词匹配和语义排序。我搭了一个完整的 RAG 流程验证：用户提问 → 向量检索 → 全文检索 → 混合排序 → 拼上下文 → 交给大模型生成。整个链路不需要把数据搬出数据库，也不需要额外引入向量库。
会话记忆
做 Agent 应用绕不开多轮对话的上下文存储。OceanBase 直接用关系表就能搞定——按 session_id 建索引，查询复杂度 O(log n)，数据量增长时性能依然稳定。这块反而是关系型数据库的老本行。
换句话说，OceanBase 的路线是把 TP、AP 和向量能力融合在同一套系统里，一份数据既能跑交易，又能跑分析，还能跑 AI 检索。对正在规划 AI 应用的政企客户来说，选型时多看这一步，未来就少折腾一次。顺带提一句，如果资源受限或者只是想在边缘侧、本地开发环境跑一套，它还有一个轻量发行版 SeekDB，功能与主版本兼容，部署门槛低很多。
维度 05
选择第一梯队品牌，才能替你兜底
选数据库，本质上是选一个长期合作伙伴。这个问题要看三个层面：营收规模决定公司能不能活下去，厂商背景决定技术积累有多深，资质认证决定能不能过信创门槛。本质上就是在选第一梯队品牌。
营收：从公开数据看，OceanBase 年营收已超过 10 亿人民币，并且保持高速增长；蚂蚁集团十几年双 11 的性能成绩是它工程能力的背书，连续 9 年稳定支撑双 11 不是靠宣传能吹出来的。
资质：OceanBase 集中式数据库连续入围央采和国测名录，通过等保三级、EAL4+ 等多项安全认证。公司客户覆盖全部政策性银行、近 7 成万亿级银行、70% 的头部保险公司、75% 的头部证券公司，以及大量政务、能源、交通、医疗、教育行业的关键业务系统，为国计民生关键业务负载提供稳定支撑。
还有一个值得关注的观察指标：有没有出现「用了以后又迁走」的案例。这个问题没有完整的公开统计数据，但从行业交流中听到的情况是，头部厂商的二次迁移率相对低不少——选对了、用住了，一般不会再来一次。反过来，那些因为承载不住而被迫二次替换的项目，代价往往比第一次迁移高得多。
写在最后
MySQL 国产替换这件事，说复杂也复杂，说简单也简单——把上面五个维度过一遍，答案基本就清晰了：
01  迁移改造量能不能接受
02  长期运营成本能不能降下来
03  内核是不是自己的
04  能不能顺带承接 AI 场景
05  厂商能不能陪你走得够远
这五个维度上，OceanBase 集中式数据库的综合表现值得认真评估。当然，以上都是我的经验和实测，最终还是要落到你自己的业务上——建议做一次完整的 POC 实测，数据不说谎，实测结果才是最终的决策依据。

《OceanBase 集中式数据库 MySQL 兼容性报告（2026 版）》，梳理了全部兼容项、不兼容项与边界条件。

如果想看，可点击「阅读原文」下载，也欢迎预约一次针对性的兼容性评估。

KEEP THE THREAD GOING

更多来源文章