Oracle 都替完了, 剩下的 MySQL 怎么办?
digoal约 10 分钟这么多年了, 现在到底还有多少 MySQL 没有被国产化替代? 怎么感觉没完没了、无穷无尽? 是增量大于被替换的速度, 还是没有找对合适的形态导致替换速度慢?
我的判断:
以前，不管是厂商还是用户，大家不管任何场景都喜欢高大上的分布式数据库, 但基本都是在大型企业、核心场景。
另一方面的真实情况，MySQL 的用户都有一本开发规约, 最终导致的结果就是单个 MySQL 的实例不会很大，几百 GB 可能顶天了，单表不会超过xxx万行。
像这样的情况，开个 MySQL 实例跟玩一样，License 不花钱, 结果就是 MySQL 增量巨大，人家继续用开源 MySQL。
反观分布式，并不是说不好，而是面向的场景不一样，导致实例增量不可能和开源 MySQL 一样，毕竟单实例复杂度和规格都不一样。
这个判断到底对不对？得有数据支撑，虽然不可能直接统计 MySQL 实例数，但是"春江水暖鸭先知"，咱们可以看厂商的行为就能推断一二。
今天咱们就来聊一聊 MySQL 国产化替代, 到底如何选择? 为什么得出的结论是集中式? 为什么 OceanBase 集中式版能成为国产 MySQL 替代赛道中的扛把子?
重新定义选型问题
最近一期安全可靠测评公告里，又新进三款。好巧不巧，新进三款全部都是集中式数据库，这已经能佐证我前面的判断了。
这下国产化替代“又多了一个选择”。但我万万没想到：客户感受居然是反的 —— 名单变长没有让选型变简单，只是把判断的责任推回给了用户。
名单只回答“能不能用”，客户要回答的是“怎么从这么多能用的产品中选出适合的”。
所以第一个问题就变成了：从产品看又站到了同一个起跑线, 选择权又推给了用户.
插一句可能不受欢迎的话： 测评等级是门槛，不是能力排序。 名单里绝大多数集中式产品是 Ⅰ 级，极少数拿到 Ⅱ 级； 其实这也是用户要的, 但还不够.
我总结了3个选型误区, 采购视角只算软件和硬件，不算三年后的人力与二次改造；兼容视角只测 SQL 能不能跑，不测备份、监控、审计、CDC 下游、字符集排序这些真正拖工期的“周边”；跑分视角只测峰值 TPS，不测 p99 抖动、混合负载和回切。
下面我给出了一个更全面的“集中式选型”打分表, 一张表打完分，答案通常就收敛了。
图 1｜通过对以上问题的分析, 可以把 31 款产品区分开来, 下面就进入以上问题的分析环节
一、省成本：省的不是 License，是机柜和人力
客户最常问“到底能省多少”。我一般分两层答： 现在省硬件和运维，未来省“不用再改一次” —— 后者往往更贵但容易被忽略。
省存储，得从写入路径讲起
MySQL InnoDB 是 B+Tree，改一行就得在页内原地改写，页分裂、碎片、redo 放大跟着来。压缩倒是能开，但它被绑在写路径上：每次写都要解压、改、重压，压缩比还被行存格式锁死。
OceanBase 走 LSM-Tree：写入先进内存 MemTable，后台转储合并成 SSTable，落盘时先做列式编码（字典、游程、增量、位压缩），再做一层通用压缩（ZSTD / LZ4 / Snappy / Zlib）。两道工序下来，同一份业务数据的落盘占用约为传统行存的 1/4 到 1/3。
图 2｜差别不在有没有压缩，而在压缩发生在写入路径的哪一步
这里给一份 OceanBase 实测数据： 存储成本降 70%–90%，同业务量硬件约为原来的 1/4–1/3，整体 TCO 降 30%–50%。
第二笔钱：把“一个业务一套库”合并掉
很多企业不是败在单库性能，而是败在库太多：订单一套、报表一套、测试一套，每套都要主备、备份、监控、容灾演练；硬件按峰值买，平均利用率不到 20%。
OceanBase 的租户不是逻辑 schema，而是带 CPU、内存、IOPS 配额的数据库实例：资源单元定规格、资源池圈边界、租户拿独立账号；CPU 走 cgroup 配额，内存是独立 MemTable 硬切分，IO 用令牌桶做权重限流。
图 3｜一个租户跑烂 SQL、内存打爆，不会拖垮其他租户
提醒一句: 压缩很好, 但别乱造
压缩不免费，别把最高压缩比当默认值。编码和压缩都吃 CPU，写密集场景我更倾向 LZ4，而不是最高档 ZSTD；LSM 还有转储合并的后台开销，合并策略要跟着写入节奏调。
二、易迁移：改多少行代码，必须是可以量化的
1、“基本零改造”每家在说，区别在于有没有把边界列出来,.
客户在问：业务代码要不要改？SQL、存储过程、驱动、周边工具怎么办？
怎么判断：看数据类型覆盖度、存储过程与函数兼容、驱动与协议能否直连、系统表与运维 SQL 可复用率、备份/监控/慢日志/IDE 等生态工具能否延续，最终落到“代码改造量”。
OceanBase 列得非常清晰, 瞟一眼就知道“大部分不用改，少数边界项微调即可。”：
应用程序 JDBC 无需改造，可直接用 MySQL 官方 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库高度还原，12 项常用运维场景全部通过；存储过程（IN/OUT/INOUT、游标、异常处理）全项通过； mysqldump、pt-query-digest可继续用；obbinlog 把 clog 转成标准 MySQL Binlog，下游 canal、Flink CDC 不用改。
同一套 OceanBase 集群里，MySQL 模式与 Oracle 模式的租户还能并存 —— 对同时要替 Oracle 的用户，这条很关键。
在实测 OceanBase 时, 也验证了这一点, 确实有不兼容的地方, 但微调即可.
SHOW ENGINE INNODB STATUS | V$ / GV$ 视图 | |
NO CACHE，接受性能损耗 | ||
sql_mode | ||
pt-oscpt-archiver 等不适用 |
而且这些项日常使用比较常见，是用户真切使用能感受到的。OceanBase 能把兼容项、不兼容项及应对方法写进手册，对用户来说交付体感就会很好。
其实用户并不是要你长得跟 MySQL 一模一样，重要的是不要开始说 100% 一样，使用时却给用户惊吓。这就像你已经迟到了，等的人打电话问你还要多久，你说 10 分钟就到，但 30 分钟才到，这种体感非常差。
三、不用二次改造：根自研的价值在“第三年”
这一节我花了最多的时间斟酌，因为容易得罪一大片人，不管你说根自研还是二次改造(发行版)，总之站一边，你就把对方得罪了。
但我为什么不把这节删掉呢？我觉得这个问题还是摆到台面上直视比较好。这个跟说 php 宇宙第一还不一样，那是无脑，二次改造和根自研两个派别还是能正常且客观的对话的。
“基于开源二次开发”短期最快：拿成熟内核加管控、加界面、加兼容层，一年出货。当然，对用户也有好处，能快速切换，人才也更容易找到。但代价是把命门交给上游 —— 上游换大版本，分支要重新合并，你改动的代码就会越来越多, 冲突将一年比一年重；上游出高危 CVE，你在“跟”与“不跟”之间进退两难；上游路线和客户需求不一致时，你没有投票权。这些问题是摆在这的，而且这个路线的发行商也不少，相信未来也许能找到好的解决办法来化解这些矛盾。
根自研呢? 需要时间的积累, 从产品、人才体系、生态到案例沉淀等各个层面, 都需要大量积累. 根自研通常还意味着更长的成熟周期，早期版本一定更难用。中间过程做过的人就知道, 坎坷无数, 没有长期的定力其实很难做到. 但只要扛过去了, 根自研的竞争力就体现出来了.
OceanBase 走的就是根自研这条路：2010 年立项，不基于 MySQL、PostgreSQL 等任何开源内核的代码，SQL 引擎、优化器、事务、LSM-Tree、Paxos 全部自研。 “上游”这个概念在它这里不存在，断供也就无从谈起，从根本上规避这个风险。
图 5｜“套壳”和“根自研”差的不是面子，是三年后的退路
不管选根自研还是“基于开源二次开发”, 尽调都应该问这三句：内核代码能否逐行追溯？上游出新版你跟不跟、等多久？断供那天谁发补丁？这些答案一定要写进标书。
站在决策层的视角，这是对供应链风险的定价问题：愿不愿意为“十年后还能自己发补丁”多付一点现在的钱。
四、面向 AI：一次选型，管三种负载
“集中式” 不是单机版! “集中式” 不是单机版! “集中式” 不是单机版!
重要的事情必须说三遍, 这是 OceanBase 集中式最容易被低估的地方 —— “集中式”只是部署形态，内核还是那个分布式内核。
集中式与分布式共用同一套底座：单机起步，业务涨了在线加副本、加 Zone，应用不改、数据不用再迁。翻译给决策层就是： 现在按 1 台买，未来按 N 台扩，中间不必再来一次信创改造。
图 6｜能力随内核演进，不随部署形态打折
行列混存 + 向量化执行让一份数据既能扛小事务高并发、又能跑复杂分析：Sysbench 高并发写入达 MySQL 8.0 的 214.99%，TPC-C 事务延迟 < 5ms，TPC-H 10TB 较上一代提升约 3 倍。
OceanBase 4.4.2 原生支持 VECTOR 类型与向量索引（HNSW / IVF，配标量量化、乘积量化、二值量化），也支持全文检索。关键是混合检索能在一条 SQL 里完成：
-- 示意：关系过滤 + 全文匹配 + 向量召回，一次返回融合排序
SELECT id, title, cosine_distance(embedding, :q_vec) AS dist
FROM kb_chunk
WHERE tenant_id = :tid
AND created_at >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND MATCH(content) AGAINST (:kw IN NATURAL LANGUAGE MODE)
ORDER BY dist ASC LIMIT 20;
给用户一个框架：向量索引在召回率、内存、构建时间之间做三角权衡 —— HNSW 快但吃内存，IVF 省内存但要调聚类，量化省空间但掉精度。
用 OceanBase “集中式”, 你可以 少一套 ES 或向量库，就少一条同步链路，也少一个“关系表已更新、向量还没同步”的一致性缺口。 这就是在关系库中整合了向量搜索、全文检索后的好处, 一份数据解决 AI 上下文管理的所有数据搜索问题，在市场中找不到第二家这样的.
五、品牌：选数据库，就是选十年后替你兜底的人
在说品牌之前, 简单粗暴点说人话，就是你的身家性命, 愿意托付给哪家银行? 城商行还是四大行? (咱先不扯保险的事)。先停三秒, 这个比喻的分量在你身家性命越多的时候越容易做出决定.
回到数据库, 说点不客气的。数据库是有“售后服务期”的基础设施：出事要人扛、有洞要人补、上新硬件要人适配。所以我建议决策层只看这三个硬指标。
营收：公开信息里，年营收站上 10 亿元量级的国产数据库厂商一只手数得过来。这不是嫌贫爱富，是研发投入的数学题——内核团队的人力成本是刚性的。
年限：OceanBase 2010 年立项至今 16 年，经历双 11 这类极端场景打磨，4000+ 客户在金融、政务、能源、运营商核心场景落地。
资质：连续入围国测与央采名录，通过等保三级、EAL4+ 等认证。 注意测评结果有效期只有三年，资质要持续维护，不是一劳永逸。
反过来看风险：行业里已经出现有厂商股东挂牌退出、股权转让的案例。这类事对客户的影响不是“产品明天不能用”，而是服务连续性 —— 版本还发不发、补丁还给不给、出事谁来。
不管最终你决定了选哪家, 都应该在合同里加三条： 代码托管安排、厂商退出时的迁移协助义务、至少 N 年维护承诺。虽然这看起来像对所有数据库厂商的不平等条约, 但现在这僧多肉少的环境就这样。
说完硬实力, 还得看落地场景, 也不必远找，OceanBase 集中式形态已经跑在：
总结
MySQL 国产替代，首选 OceanBase 集中式。如果你想采购 OceanBase, 可随时联系我, 高低给兄弟弄个内部折扣.
如果你正在做 MySQL 国产化替代评估，可以预约一次针对现有版本、应用和负载的兼容性评估，或直接申请 POC；也建议先看看《OceanBase 集中式数据库 MySQL 兼容性报告（2026 版）》, 点击阅读原文即可获得。
点击下方阅读原文链接