为了满足业务 AP 要求，还增加了 OceanBase 与其它数据库品类的对比，结果表明：

在以 TP / AP 为主要场景进行落地、承接 MySQL、StarRocks 等组件业务的同时，在某业务生产环境高频聚合 SQL 场景下， OceanBase 综合性能优于其它品类数据库，其中 JOIN 聚合查询领先 81.5 倍，充分体现行列混存架构优势。

测试验证数据如下：

得物数据库选型慎重，对稳定性要求高。近来随着多云、AI、向量等多种战略目标的制定，OceanBase 在稳定性、性能、成本等方面优势逐步凸显，基于 OceanBase 的验证、推广落地也逐步展开。

DBA 验证评估

在实际业务推广前，DBA 端进行了详细压测验证，基于不同并发度和行列存储场景，OceanBase 表现出较好的性能水平。

高并发支持: 在不同的读写模式下，OceanBase 展现出优异的吞吐量表现（TPS 和 QPS）。例如，在 200 并发下，行列混存模式的 TPS 值高达 13076.91，显示出其优秀的处理能力，适合高并发的在线事务处理（OLTP）场景。

高效的读写性能：在只读和只写模式下，行存表、列存表的性能表现均较为突出。在 100 QPS 情况下，OceanBase 的 TPS 值能够达到 7230 左右，表明它能够高效处理大量查询请求，适合大规模数据的分析需求（OLAP）。

资源利用率：CPU 使用率在不同负载下表现合理。例如，在 200 并发下，行存表的 CPU 使用率为 63.73%，显示出其在高负荷下的良好资源分配能力。这能够确保系统的稳定性和可靠性。

灵活的存储引擎：OceanBase 支持行存、列存及混合存储，能够根据不同的业务需求和数据特性选择最优的存储模式，从而提高处理效率。

压测和结论参考下图：

复杂查询是数据库的验证重点，验证过程中，DBA 团队同时深度对比了 MySQL 和 OceanBase 在复杂查询，比如 聚合查询、分页排序查询等场景中的表现。

如下 SQL1 和 SQL2 分别用于获取某一周期内 SQL 审核的执行情况统计和分页排序查询明细情况：

SQL1：

select count(distinct(a.field_A)) as count,
SUM(CASE WHEN b.`field_B` IN (0,1,3,7) THEN 1 ELSE 0 END) AS `total_cnt`,
SUM(CASE WHEN b.`field_B` IN (0) THEN 1 ELSE 0 END) AS `todo`,
SUM(CASE WHEN b.`field_B` IN (1,7) THEN 1 ELSE 0 END) AS `done`,
SUM(CASE WHEN b.`field_B` IN (3) THEN 1 ELSE 0 END) AS `auto`
from table_A a  join table_B b on a.field_A = b.field_C
and b.`field_B` IN (0,1,3,7) and b.create_time >= {START_TS} and b.create_time < {END_TS}
where  a.is_deleted in (0)

SQL2：

select a.*, SUM(CASE WHEN b.`field_B` IN (0,1,3,7) THEN 1 ELSE 0 END) AS  `totalCount` ,
SUM(CASE WHEN b.`field_B` IN (0) THEN 1 ELSE 0 END) AS `amount`,
SUM(CASE WHEN b.`field_B` IN (1,7) THEN 1 ELSE 0 END) AS `done`,
SUM(CASE WHEN b.`field_B` IN (3) THEN 1 ELSE 0 END) AS `auto`,
sum(IF( b.create_time >= {START_TS} and b.field_B = 0, 1, 0)) as amount_current
from table_A a  join table_B b on a.field_A = b.field_C
and b.`field_B` IN (0,1,3,7) and b.create_time >= {START_TS} and b.create_time < {END_TS}
where  a.is_deleted in (0) group by field_A order by amount desc limit 0, 10

这两个是常见的复杂查询 SQL，在 MySQL 中的执行计划调到最优，耗时也需要 1.3s 和 3.9s。

在 OceanBase 中对相同的 SQL 进行测试，并进行优化对比， 性能提升效果明显：通过 5 个维度的渐进式优化，将 SQL2 执行时间从 4s 降至 0.02s，整体性能提升约 200 倍；SQL1 从 1.3s 降至 0.01s，提升约 130 倍。

下图详细介绍这几项优化的思路：

OceanBase 通过计划缓存复用、分区裁剪减少扫描、列存索引破最左前缀瓶颈、多核并行执行提速、Hint 指定算法五大特性，从 “计划生成→数据扫描→索引选择→执行调度→算法决策” 全链路压缩复杂 SQL 的执行开销。

需要指出的是，OceanBase 提供了丰富的执行计划 Hint， 让 DBA 可以在 SQL 中直接指定算法，精准干预执行计划的生成。

OceanBase 的执行计划 Hint 不是日常调优工具，而是优化器偏差时的兜底干预能力——当生产 SQL 突发劣化、统计信息失准或关联条件复杂导致选错算法时，DBA 可直接在 SQL 中指定算法纠正执行计划，无需改写 SQL，这份能力是 MySQL 所不具备的。

下图是团队基于 OceanBase SQL 查询计划和 OceanBase SQL Hint 的详细拆解和分析。

业务 POC

在正式推广业务之前，OceanBase 在 DBA 团队内部尝试，DBA 内部 AP 报表业务试点，SQL 执行速度平均提升 10-30 倍。

DBA 报表业务一直基于 MySQL，存在复杂查询耗时长的问题，大部分超过 1 秒，甚至有超过 30s 才能执行成功，同时复杂查询带来的资源互斥、锁等待等运维问题。

DBA 内部报表业务整体切换到 OceanBase，使用 OceanBase 物化视图、行列混存等特性，SQL 执行速度平均提升 10-30 倍，同时通过混沌工程，验证 OceanBase 在各异常场景下的止血手段并形成运维 SOP，积累 OceanBase 运维经验，提振 DBA 团队把 OceanBase 面向业务落地的信心。

第一个“吃螃蟹”的业务

在 DBA 内部尝试积累了实践经验后，我们对某业务团队的系统进行了综合评估，该团队共管理多套 MySQL 集群，总规模达百核 CPU、存储量 TB 级，有以下业务痛点：

TP & AP 混查，CPU 等告警频发：普遍没有只读实例，同时存在大量复杂聚合查询，长期对 TP 业务查询造成较大资源挤占，CPU 经常告警。
磁盘容量问题凸显：部分 AI 相关 MySQL 磁盘增长迅速，B+Tree 架构下碎片明显；大表较多，执行 DDL 所需预留额外空间较大，磁盘成本压力显著。
资源分配不合理：QPS 较低的实例较多，即使在最低配置下也存在资源浪费。
运维处理复杂：存在大量空长事务及异常 DML，常规管控平台无法快速排查。

基于业务团队目前遇到的切实痛点，DBA 团队构建了全面的切换计划，涵盖 平台接入、资源规划、架构设计、集群配置、迁移变更等各个环节。

整体流程图如下：

业务整体切换完成后，数据库架构升级，SQL 平均耗时下降 88.3%，业务超时接口清零，总体降本 43%。

架构清晰简洁，多套 MySQL 集中到 1 套 OB 集群，多租户隔离；三个主机便承载团队整体业务，并同时兼顾高可用和 TP / AP 业务资源隔离。集群底层宿主机为云 ECS 实例，共三个 Zone，分别部署在两个可用区，可用区 A 两个 Zone 用于读写业务，可用区 B 一个 Zone 用于只读业务，每个 zone 由若干计算节点组成。集群中也会留出部分冗余 CPU 资源，当租户出现 CPU 告警时，冗余 CPU 可以秒级完成租户的 CPU 扩容。

整体架构如下：

SQL 平均耗时下降 88.3%，业务超时接口清零，性能提升 8.6 倍，聚合 / 范围查询响应时间较 MySQL 降至 1% 以内，以某研发效能平台为例，AP 相关 SQL 平均耗时从 6.87s 降至 0.8s，性能提升约 8.6 倍，耗时下降 88%。

详细数据如下：

切换后，成本收益明显，相比 MySQL 总体下降 43%，主要体现在存储方面，MySQL 切换到 OceanBase 后，压缩率 80% 以上，简单字段场景压缩比可达 10:1 以上。

资源利用上，基于 OceanBase 特有的多租户 PrimaryZone 打散 + CPU 超卖，将集群 ECS CPU 利用率提高到 100%，远超 MySQL 主备架构的 50%。

第一个“大换血”的业务

数据库底座重组，在有了第一次业务经验后，寻找新“战机”，了解到另外一个业务团队当前有切身痛点：

传统 MySQL 架构：业务库会在 MySQL 下游接入异构从库，用于业务 B 端运营数据聚合查询。
多套异构数据库支撑业务：运营 B 端原先全走另一家数据库，商家 B 端大活动查询也是，只有小活动查询走 MySQL，通过数据同步工具从 MySQL 异构同步到其他品类数据库。
业务分流痛点：需要业务手动分流点查 / 聚合查询，而这种分流时常不准确，出现聚合查询走到 MySQL 影响业务的情况。
存储数据量大：两个数据库的组合，占用了大量的存储空间，后续数据一致性依赖同步工具保障。
AP 查询性能急需优化：虽然业务对部分组件进行了拆分以提升查询效率，查询仍然存在提升空间。

在经过全面的 POC 验证及测试后，OceanBase 很好地解决了当前问题，特别是架构痛点，在承载 MySQL 业务的同时，压缩率及性能上均较原数据库更优，在与研发业务高效协作后，对当前架构进行“大换血”，目前已将原数据库的部分流量切到 OceanBase 进行 POC，运营 B 端已全部走 OceanBase。并且整体效果超出预期。

架构升级：从双链路 + 应用层手动分流升级为 OceanBase 行列混存一体化。
消除异构：消除数据同步工具链路，数据从异步滞后到实时可见转变。
业务分流风险消除：消除应用层手动分流，OceanBase 内部自动路由点查 / 聚合，彻底杜绝分流错误影响业务的风险。
存储降本：存储从数 TB 级降至百 GB 级，较 MySQL 压缩率达 94%，较原数据库压缩率达 30%。
SQL 提效显著：OceanBase 的聚合 / 范围查询响应时间较原数据库平均降低 65%（10%-90%），较 MySQL 降至 1% 以内；高 QPS 点查与 MySQL 互有优势，且显著优于原数据库。实时性方面，OceanBase 查询完全实时无延迟，而原数据库存在秒级写入-读取延迟。

目前报表业务及部分 TP 业务已完成 OceanBase 切换，虽然带来性能和成本的双重好处，但过程中也遇到不少问题和挑战，除了性能问题，还包括兼容性等问题。

切换挑战

在 OceanBase 最新的 LTS 版本 4.4.2 实践中，需注意与 MySQL 在 SQL 语法、事务隔离级别、自增列实现等方面的差异，通过业务适配或参数调整解决兼容性问题。性能方面，通过绑定执行计划、错峰刷新物化视图等手段，有效解决了 AP 查询走偏、物化视图卡住等瓶颈。

更重要的一点是，从传统数据库如 MySQL 等切换至 OceanBase 时，引入新特性需要特别小心，因为新特性新功能也仍在完善中，不可避免有场景限制甚至功能互斥，比如这里遇到的实时物化视图与 DDL 冲突问题，在引入新功能时须建立严格的准入审核、监控告警和故障演练机制。上线前应全面评估，避免对业务造成非必要影响。

在保障业务稳定性、可用性前提下，通过切换 OceanBase 来获得性能、成本双重提升，特别是在接下来进入深水区、核心业务推广时，还有不少切实需要解决的问题，需要沉淀总结的经验。

运维体系转型

运维模式从实例级转为租户级 + 集群级，在监控、备份和容量规划上全面适配 OceanBase 的分布式特性。工具链也相应升级，从云 MySQL 的 “控制台 + 数据同步工具 + 数据库诊断工具 + 自研 DBA 管控平台” 切换为 OceanBase 的 “OCP + OMS + diag + ODC / 自研 DBA 管控平台” 体系，实现管控、迁移、诊断与开发的全链路覆盖。

DBA 团队对 OceanBase 知识框架也进行了梳理：