胖头鱼的技术专栏-481 MySQL 替代怎么选？聊聊 OceanBase 集中式的五个优势（20261026）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

MySQL 国产替代，面对的往往是一套已经运行多年的系统。应用里的 SQL、定时跑批、监控脚本，还有上下游的数据同步，都已经围绕它建立起来了。换数据库时，这些投入能保留多少，会直接影响项目能不能做下去。

我在 第 397 期《国产数据库的兼容性，是不是必须？》里讨论过这个问题。客户既希望完成替换，又希望应用少改、迁移可控，之后维护和业务增长还有着落。

选 MySQL 的替代产品，要把当下的替换成本和之后的使用放在一起考虑。以 OceanBase 集中式为例，省成本、易迁移、自主可控、AI 演进和长期服务，这五个维度值得放进同一张选型表。

1. 省成本，压缩与多租户各有作用

用惯 MySQL 的团队评估替代产品，新增的软件采购是一项支出，也会关心之后的服务器、存储和维护投入。OB 在这里有两项具体能力：编码压缩和原生多租户。

OB 使用基于 LSM-Tree 的存储引擎，通过编码与压缩减少持久化数据的占用，同一业务的数据存储量，OceanBase 硬件消耗仅为 MySQL 数据库的1/4-1/3，有效降低存储成本70%-90%。原生多租户则让多个业务在资源配额管理下共享服务器资源，从应用视角看，每个租户仍像一个独立的数据库实例，按需分配、峰谷互补。根据实践数据，OceanBase 多租户资源整合方案可以帮助企业 TCO（总体拥有成本）降低30%-50%。

压缩减少数据占用，多租户减少各业务单独预留资源造成的浪费。这也是我在 第 415 期讨论数据库成本时关注过的方向，相关技术在集中式和分布式部署中都能发挥作用。

说白了，这有点像合租：房间各自使用，公共设施一起分摊。但几个业务若都在晚上跑批，就得为重叠高峰留足资源。平均 CPU 利用率低，不代表高峰时一定能合并部署。

我会以原有 MySQL 部署为基线，在相同业务量、延迟和恢复目标下比较投入。压缩之后还要规划日志、备份和合并余量，硬件之外还要算授权、实施与维护。

2. 易迁移，尽量保留已有应用投入

OB 集中式 V4.3.5 对 MySQL 5.7/8.0 绝大部分功能与语法的兼容，使已有 SQL、驱动和开发习惯有了继续使用的基础。其价值很直接： 减少为了更换数据库而重新开发、联调的工作。

应用能否沿用 MySQL JDBC 驱动，要结合驱动版本、认证方式和目标版本确认。 兼容性说明也列出了系统视图、存储引擎等差异。 “少改”的依据，应当是本应用的兼容验证结果。

例如，联调时可以先在两端分别记录下面这些配置。这是核对方法，不是本篇实测；不同版本只会返回其支持的变量。

SHOW VARIABLES
WHERE Variable_name IN (
  'sql_mode',
  'character_set_connection',
  'collation_connection',
  'transaction_isolation',
  'tx_isolation'
);

空日期如何处理、字符比较是否区分大小写，都可能影响业务结果。配置对齐以后，还要验证真实 SQL 和事务，尤其是提交超时后的状态确认与重试。监控、CDC 等周边链路，也应按实际使用方式核对。

迁移可以根据停机窗口安排。数据量和窗口允许时，停写后搬迁、校验再切换；窗口较短时，可以借助 OMS 等工具，以全量迁移加增量同步减少窗口内的工作，任务支持范围需按版本确认。

在线迁移能够缩短停机窗口，正式切换仍需演练停写、追平、校验和业务恢复。兼容与迁移工具一起用，才能把应用改造量和上线风险降下来。

3. 根自研，把自主可控落实到内核

国产升级涉及自主可控，也涉及以后遇到复杂问题时，厂商能否持续定位、修复和演进内核。这一点应在选型时就问清楚。

OB 的 产品资料将自身技术路线概括为“根自研”：它兼容 MySQL 的协议与语法，底层使用自己的 SQL、事务和存储引擎。 应用兼容与内核自主研发可以同时成立：已有应用的接入方式得以延续，底层技术路线由厂商自主推进。

我之前写过 第 263 期《VLDB：OceanBase Paetica》，也在 第 313 期部署过集中式企业版，体验了多租户和 Oracle 模式的基础功能。OB 的集中式分布式一体化，有明确的架构积累。

Paetica 将数据分区与日志流的管理粒度分开，多个 Tablet 可以共用日志流，单日志流事务可以省去跨日志流的两阶段提交。这类设计，为同一套内核适应不同规模的部署提供了技术基础。

分布式在横向扩展、数据分布和副本一致性方面的积累，可以继续服务需要这些能力的业务；集中式则提供适合相应容量和负载的部署选择。企业可以长期同时使用两种形态，并复用部分适配与运维经验。

减少二次信创改造，需要把当前的自主可控要求与后续技术路线一起评估。OB 自主掌握的内核和统一技术体系，为沿用已有投入提供了条件；具体的软硬件适配、产品版本及资质范围，仍需与项目要求对应。

4. 面向 AI 演进，给后续业务留出选择

数据库替换完成以后，需求还会继续变化。数据量增长、业务要看实时报表、知识库要增加语义检索，都可能影响之后还要引入多少组件。

OB 在这里值得关注的是集中式分布式一体化、HTAP，以及 向量和多模数据处理能力。它们分别对应容量扩展、事务数据分析与 AI 检索需求。

现有业务适合集中式，可以继续使用；需要水平扩展时，再评估转为分布式的流程与业务影响。 共用内核有助于延续技术栈，集中式与分布式按各自适用条件选择。

HTAP 的吸引力，是事务数据可以直接用于实时分析，部分场景能减少为报表单独建设数据搬运链路的工作。比如订单写入后，业务希望尽快看到统计结果，就可以评估在同一数据库中完成分析，同时观察查询对交易延迟的影响。

AI 场景则更贴近数据的组合使用。以一个假设的售后知识检索为例，需要结合客户权限、设备型号和文档相似度筛选结果。关系数据、JSON、全文及向量检索放在同一技术体系中，有机会减少跨系统拼接和重复同步。

我更看重的是： 本次替换之后，新增需求能否复用已有数据、权限和维护经验。向量检索仍需规划嵌入生成与更新、权限过滤及检索效果，HTAP 也要验证混合负载，功能具备后才有条件讨论怎样用于业务。

5. 品牌与服务，关系到上线以后的每一天

数据库会长期运行，选型也要看厂商的持续研发、交付和服务能力。OB  从 2010 年开始研发，历经蚂蚁集团双11大规模并发场景，并且已经在党政、金融、通信、能源、交通、医疗、教育等关键行业积累了关键业务运行经验。对我来说，这些经历的价值在于产品与服务体系经过了长期使用与成熟度验证。

集中式也能延续这套支持体系。 官方文档明确，其提供与分布式版同等规格的售前、售后、咨询及培训服务；OCP、ODC、OMS 等工具也已经支持集中式。

品牌积累的实际价值，是业务上线以后，问题有人持续处理，版本有人持续维护。而品牌选择的逻辑很简单——要选就选头部的第一梯队品牌，从 OB 今年公布的 14 亿营收来看，已经稳居前列。OB 的集中式产品已经披露通过国家安全可靠测评，采购时仍应核对具体产品、版本和有效范围。同类案例可以帮助评估，也要看负载与部署条件是否接近。

技术方案也要落实恢复目标。V4.3.5 集中式支持物理备份恢复和租户级物理备库，后者异步同步日志，仅支持最大性能模式。计划切换与故障接管分别确认条件；业务若要求容灾切换保证数据强一致，应评估分布式版的多副本或仲裁方案。

这些内容最好在 POC 和合同阶段确认，并演练恢复后的业务访问。数据库恢复提供服务以后，连接池和下游链路也恢复了，业务才算恢复。

总结

在 MySQL 替代选型中，OB 集中式的五个优势要对应到具体工作。压缩与多租户改善资源使用，兼容和迁移工具减少改造投入，自研内核支撑自主可控，统一技术体系提供扩展与 AI 演进选择，品牌积累和服务体系支持长期运行。

我会把这些能力放进本企业的应用、负载和恢复要求中验证。今天替换所花的投入，之后业务增长还要付出的工作，以及上线后能获得的支持，都应该在同一次选型里考虑。这样选出来的数据库，才更容易持续用下去。

老规矩，知道写了些啥。