复杂SQL优化200倍的背后：得物OceanBase执行计划与Hint调优实战（技

一背景得物是全球领先的集正品潮流电商和潮流生活社区于一体的新一代潮流生活方式平台。复杂的业务场景和极致的用户体验追求对数据库运维和选型提出了更高要求。目前得物在线的数据库服务涵盖 MySQL、TiDB、MongoDB、HBase、DuckDB、ClickHouse / StarRocks、向量数据库等多品类支撑核心交易、运营分析、AI 算法、社区等多业务场景。多品类数据库面临运维复杂度高、研发选型难、架构复杂、资源成本高等运维问题。同时业务对数据库性能、可用性、成本要求逐步增高。在持续的数据库调研和选型中OceanBase 作为多模数据库逐步进入视野特别是 4.x 版本引起了 DBA 团队和研发团队的极大兴趣。二多模数据库 OceanBase 选型OceanBase 基于 Paxos 协议实现多副本强同步支持单机房到三地五中心多种部署模式任意副本秒级故障接管RPO 0RTO 8s。同时支持多活与单元化部署实现跨地域同时写入、跨云灵活扩展毫秒级同步延迟保障数据一致。在当前业务对可用区级高可用日益迫切的需求下OceanBase 多活架构提供了从容灾到合规的全方位高可用保障。总体来看OceanBase 能力与公司业务场景、痛点高度匹配**灵活架构**单机分布式一体化能力让零散 MySQL 小业务从最小规模起步随增长无缝扩展至分布式集群同时通过多租户机制按需分配资源解决小业务整合难、扩展需迁移切换的痛点实现成本与弹性的最优平衡。**降低成本**通过分层转储、增量合并和两层压缩在保障高性能写入的同时大幅压缩存储成本降幅可达 40%解决 MySQL 类业务存储成本高、写放大严重的痛点。**分层转储**内存数据经 L0 → L1 → L2 三级 SSTable 逐层下沉避免内存阻塞保障写入持续性。**增量合并**仅合并被修改的热点宏块未修改数据直接复用有效减少合并开销降低写放大。**两层压缩**先以行列混存编码对结构化数据做字典压缩再用通用算法二次压缩在性能与压缩率之间灵活平衡大幅削减存储成本。**高可用**原生多活架构基于 Paxos 协议支持任意副本秒级故障接管、RPO 0RTO 8s 及跨地域多活写入满足业务对可用区级高可用的严苛要求解决容灾切换慢、异地数据一致性弱、合规部署复杂的痛点。为了满足业务 AP 要求增加了 DuckDB / HBase 等品类对比验证在以 TP / AP 为主要场景进行落地、承接 MySQL、StarRocks 等组件业务的同时在某业务生产环境高频聚合 SQL 场景下OceanBase 综合性能优于 DuckDB4:2 胜出其中JOIN 聚合查询领先 81.5 倍充分体现行列混存架构优势DuckDB 在纯列存大列表过滤场景略有优势1.3x除了 DuckDB还初步进行了与 HBase 的性能对比但结果不如预期因磁盘类型导致 IO 能力存在差距OceanBase 部署时使用同盘环境空跑时磁盘 IO 延迟在 2~3ms如使用 SSD 磁盘进行分盘部署性能存在明显提升后续会跟进新版本优化并和社区共建持续进行调研及方案优化。详细测试验证数据如下三落地实践得物数据库选型慎重对稳定性要求高。近来随着多云、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 审核的执行情况统计和分页排序查询明细情况SQL1select 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)SQL2select 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 磁盘增长迅速BTree 架构下碎片明显大表较多执行 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 端原先全走 StarRocks商家 B 端大活动查询走 StarRocks小活动查询走 MySQL通过数据同步工具从 MySQL 异构同步到其他品类数据库。**业务分流痛点**需要业务手动分流点查 / 聚合查询而这种分流时常不准确出现聚合查询走到 MySQL 影响业务的情况。**存储数据量大**StarRocks MySQL 占用了大量的存储空间后续数据一致性依赖同步工具保障。**AP 查询性能急需优化**虽然业务对部分组件进行了拆分以提升查询效率查询仍然存在提升空间。在经过全面的 POC 验证及测试后OceanBase 很好地解决了当前问题特别是架构痛点在承载 MySQL 业务的同时压缩率及性能上均较 StarRocks 更优在与研发业务高效协作后对当前架构进行“大换血”目前已将 StarRocks 部分流量切到 OceanBase 进行 POC运营 B 端已全部走 OceanBase。并且整体效果超出预期。**架构升级**从 MySQL StarRocks 双链路 应用层手动分流升级为 OceanBase 行列混存一体化。**消除异构**消除数据同步工具链路数据从异步滞后到实时可见转变。**业务分流风险消除**消除应用层手动分流OB 内部自动路由点查 / 聚合彻底杜绝分流错误影响业务的风险。**存储降本**存储从数 TB 级降至百 GB 级较 MySQL 压缩率达 94%较 StarRocks 压缩率达 30%。**SQL 提效显著**OceanBase 的聚合 / 范围查询响应时间较 StarRocks 平均降低 65%10%-90%较 MySQL 降至 1% 以内高 QPS 点查与 MySQL 互有优势且显著优于 StarRocks。实时性方面OceanBase 查询完全实时无延迟而 StarRocks 存在秒级写入-读取延迟。更多迁移收益和对比数据参考下图四落地遇到的问题及解决方案目前报表业务及部分 TP 业务已完成 OceanBase 迁移虽然带来性能和成本的双重好处但迁移过程也遇到不少问题和挑战除了性能问题还包括兼容性等问题。迁移挑战在 OceanBase 最新的 LTS 版本 4.4.2 实践中需注意与 MySQL 在 SQL 语法、事务隔离级别、自增列实现等方面的差异通过业务适配或参数调整解决兼容性问题。性能方面通过绑定执行计划、错峰刷新物化视图等手段有效解决了 AP 查询走偏、物化视图卡住等瓶颈。更重要的一点是从传统数据库如 MySQL 等迁移到 OceanBase 时引入新特性需要特别小心因为新特性新功能也仍在完善中不可避免有场景限制甚至功能互斥比如这里遇到的实时物化视图与 DDL 冲突问题在引入新功能时须建立严格的准入审核、监控告警和故障演练机制。上线前应全面评估避免对业务造成非必要影响。在保障业务稳定性、可用性前提下通过迁移 OceanBase 来获得性能、成本双重提升特别是在接下来进入深水区、核心业务推广时还有不少切实需要解决的问题需要沉淀总结的经验。以下为迁移过程中遇到的问题和总结例如实时物化视图和 DDL 相冲突、SQL 语法不兼容、用户连接字符串被转义等运维体系转型运维模式从实例级转为租户级 集群级在监控、备份和容量规划上全面适配 OceanBase 的分布式特性。工具链也相应升级从云 MySQL 的 “控制台 数据同步工具 数据库诊断工具 自研 DBA 管控平台” 切换为 OceanBase 的 “OCP OMS diag ODC / 自研 DBA 管控平台” 体系实现管控、迁移、诊断与开发的全链路覆盖。DBA 团队对 OceanBase 知识框架也进行了梳理团队能力建设通过 “基础培训 — 深度实践 — 认证培养” 三层路径DBA 团队系统提升从 OceanBase 架构原理到性能调优的实战能力并通过达成 OBCP 认证目标已建立 OceanBase 系统化知识体系框架训练出 OceanBase 专项运维人员。同时基于技术分享、项目实战带教和内部知识库等途径形成 “分享 — 实战 — 沉淀” 的知识转移闭环持续提升团队能力。五未来规划与架构演进未来 OceanBase 在团队中的规划将逐步进入核心区、深水区同时从成本、性能、效率、AI 智能、AI Agent 底座等多维度为业务赋能提效。大致分三个阶段推进短期0.5-1 年夯实基础建立技术支撑、标准 SOP 和应急演练体系中期1-2 年引入 OBKV 落地业务场景、上线向量检索完成多云多可用区建设并引流核心新增业务长期2-3 年建成统一多模数据平台覆盖 90% 数据场景。围绕 AIOps 方向从异常检测、根因分析、容量预测到自动调参构建智能运维全链路能力实现性能预警、故障自愈和资源规划的自动化与智能化。以 OceanBase 迁移为契机实现成本、敏捷性、创新与风险四大收益3 年内 TCO 降低 50%业务上线准备缩短至 1 天内覆盖实时分析与个性化推荐等新场景并达成秒级故障恢复与数据零丢失。持续推动 OceanBase 的全面落地关注并调研 OceanBase LakeBase 等面向 AI 底座的数据库产品团队将致力于构建面向未来、面向 AI Agent 的多模多态数据基础设施解决业务当前痛点为业务创新提供坚实数据底座支撑。“扫码添加小助手微信如有任何疑问或想要了解更多技术资讯请添加小助手微信立即试用 OceanBase 企业版体验国产数据库能力立即试用