OceanBase 是蚂蚁集团自研的分布式关系型数据库，已在支付宝核心交易、账务等场景支撑海量并发。它最大的卖点是「一套引擎同时兼容 MySQL 与 Oracle 语法」，又能通过 Paxos 多副本做到 RPO=0、RTO 小于 30 秒的高可用。本文从架构到落地，带你在本地用 Docker 拉起一个三节点集群，并完成建表、分区、调优与备份恢复的完整闭环。
一、为什么需要 OceanBase：从单机 MySQL 到分布式
单机 MySQL 在海量数据与高并发下会遇到两个天花板：一是单机容量上限，二是主从异步复制存在数据丢失窗口。传统解法是用 MySQL 主从复制与读写分离 做扩展，但运维复杂且强一致难保证。OceanBase 把「分布式」做进数据库内核：数据按分区打散到多个节点，写请求通过 Paxos 协议在多数派副本间达成共识，从而在不牺牲一致性的前提下水平扩展。
二、核心架构：Paxos 多副本与 OBProxy
2.1 多副本强一致
每个分区（Tablet）默认有 3 个副本，分别位于不同 Zone（可用区）。Leader 副本处理读写，Follower 通过 Paxos 同步日志。只要多数派存活，集群即可对外服务，单机房故障不影响整体可用性。
2.2 无状态 SQL 层与 OBProxy
OceanBase 的 SQL 计算层与存储层分离，客户端经由 OBProxy 路由到正确的 Leader 分区。OBProxy 本身无状态，可水平扩缩，这也是它与传统单体数据库在接入层上的关键差异。
三、用 Docker 快速拉起三节点集群
下面用 docker-compose 启动 3 个 observer 与 1 个 OBProxy。部署本身依赖容器编排能力，相关基础可回顾 Docker 编排实战。
version: "3"
services:
obproxy:
image: oceanbase/obproxy-ce:4.2.1
ports: ["2883:2883"]
command: -c "obproxy -n obcluster -o rs_list=observer1:2881;observer2:2881;observer3:2881"
observer1:
image: oceanbase/oceanbase-ce:4.2.1
environment:
OB_CLUSTER_NAME: obcluster
OB_SERVER_ID: 1
OB_ZONE: zone1
ports: ["2881:2881"]
observer2:
image: oceanbase/oceanbase-ce:4.2.1
environment:
OB_CLUSTER_NAME: obcluster
OB_SERVER_ID: 2
OB_ZONE: zone2
observer3:
image: oceanbase/oceanbase-ce:4.2.1
environment:
OB_CLUSTER_NAME: obcluster
OB_SERVER_ID: 3
OB_ZONE: zone3
首次启动后需通过 obclient 初始化集群（设置 RootService 列表、创建资源单元与租户）。官方文档提供了完整的 bootstrap 脚本，建议先在小规格单机验证，再推广到生产多机环境。
四、连接并建库建表
OceanBase 兼容 MySQL 协议，直接用 mysql 客户端或 obclient 即可连接，默认端口 2881。
mysql -h127.0.0.1 -P2881 -uroot@sys -p
-- 进入业务租户后建库建表
CREATE DATABASE shop;
USE shop;
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id BIGINT NOT NULL,
amount DECIMAL(10,2),
created_at DATETIME NOT NULL
) PARTITION BY HASH(user_id) PARTITIONS 8;
五、MySQL 兼容性与迁移注意点
OceanBase 的 MySQL 模式兼容绝大多数 DDL、DML 与常用函数，但仍有细节差异，迁移前务必做语法与数据类型核对。与 ScyllaDB 这类宽表 NoSQL 不同，OceanBase 提供完整 ACID 与 SQL 能力，更适合强事务业务。
| 维度 | OceanBase | MySQL 主从 | TiDB | PolarDB |
|---|---|---|---|---|
| 一致性模型 | Paxos 强一致 | 异步/半同步 | Raft | 共享存储 |
| 水平扩展 | 分区打散 | 需中间件 | 自动分片 | 计算节点扩缩 |
| Oracle 兼容 | 支持（Oracle 模式） | 否 | 否 | 否 |
| 典型场景 | 金融核心/海量并发 | 通用 Web | HTAP | 云上托管 |
六、分区表与水平扩展实战
分区是 OceanBase 水平扩展的核心。除 HASH 外，RANGE 分区适合按时间滚动的数据（如订单、日志）。合理分区能让查询只扫描相关分区（分区裁剪），配合 GitHub Actions 在发版时自动管理分区边界，可避免大表全表扫描。
CREATE TABLE order_log (
id BIGINT,
user_id BIGINT,
created_at DATETIME,
PRIMARY KEY(id, created_at)
) PARTITION BY RANGE(TO_DAYS(created_at)) (
PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
PARTITION p202602 VALUES LESS THAN (TO_DAYS('2026-03-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
七、性能调优：执行计划与关键参数
调优第一步是看执行计划。OceanBase 的 EXPLAIN 与 MySQL 类似，但会显示分区扫描与并行度，重点关注是否命中分区裁剪、是否走索引。
EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND created_at > '2026-01-01';
-- 关注输出中的 PHY_TABLE_SCAN 是否命中分区裁剪、是否走索引
ALTER SYSTEM SET parallel_max_servers = 32; -- 提升大查询并行度
ALTER SYSTEM SET memstore_limit_percentage = 60; -- 控制内存表写入上限
| 参数 | 作用 | 调优建议 |
|---|---|---|
| parallel_max_servers | 单查询最大并行线程 | 大查询上调，避免小查询浪费 |
| memstore_limit_percentage | MemStore 占内存比 | 写入多则调高至 50-70% |
| cpu_quota_concurrency | CPU 并发度 | 高并发场景适当放大 |
| minor_freeze_times | 转储触发阈值 | 写入峰值前预调 |
八、高可用与备份恢复
OceanBase 的备份基于归档日志（Clog）与基线数据。可用系统命令发起物理备份到 OSS 或 NFS，并支持按时间点恢复（PITR）。配合 Redpanda 等流平台，还能把 OceanBase 的 CDC 日志实时投递到下游做异构同步。
ALTER SYSTEM BACKUP DATABASE shop TO 'oss://bucket/ob-backup';
-- 恢复时指定目标时间点（PITR）
ALTER SYSTEM RESTORE shop FROM 'oss://bucket/ob-backup' UNTIL '2026-01-15 08:00:00';
九、生产落地检查清单
| 检查项 | 达标标准 |
|---|---|
| 副本分布 | 3 副本跨 3 个 Zone，无单点 |
| 资源单元 | 租户 CPU/内存按峰值预留 |
| 分区策略 | 大表全部分区，避免单分区过大 |
| 备份验证 | 每月至少一次恢复演练 |
| 监控告警 | 慢 SQL、副本延迟、MemStore 水位告警 |
| 连接管理 | 经 OBProxy，连接池限流防雪崩 |
十、连接池与 OBProxy 接入调优
生产环境不要直连 observer，统一走 OBProxy，并在应用侧配置连接池（如 HikariCP、Druid）。OBProxy 会自动把请求路由到对应分区的 Leader，但客户端需要控制并发连接总数，避免瞬时建连把 Proxy 打满。连接配置建议纳入 GitHub Actions 流水线统一注入，避免在不同环境手写错。
// HikariCP 关键配置示例
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.connection-timeout=3000
spring.datasource.hikari.idle-timeout=600000
jdbc:mysql://obproxy:2883/shop?useSSL=false&serverTimezone=UTC
十一、慢 SQL 治理与监控告警
OceanBase 提供内部视图（如 GV$SQL_PLAN_MONITOR、oceanbase.DBA_OB_SQL_AUDIT）来定位慢查询与全分区扫描。将其接入 Prometheus + Grafana 可形成持续可观测能力，监控思路与 Prometheus 监控 一脉相承：采集、告警、看板三段式落地。
| 监控指标 | 含义 | 告警阈值建议 |
|---|---|---|
| 慢 SQL 数量 | 执行超过阈值的 SQL 条数 | 5 分钟超 50 条告警 |
| 副本延迟 | Follower 与 Leader 日志差距 | 持续大于 1 秒告警 |
| MemStore 水位 | 内存表占用比例 | 超过 80% 预警 |
| OBProxy 连接数 | 接入层活跃连接 | 接近上限 80% 告警 |
十二、从 MySQL 迁移的最小风险路径
不要一次性全量切换。建议采用「双写校验 → 灰度读 → 全量切读 → 停写旧库」的四步法：先以只读或双写方式把 OceanBase 作为影子库，用比对工具校验数据一致性；确认无误后再把读流量按比例切到 OceanBase，最后停止旧库写入。整个过程把 GitHub Actions 的数据库迁移 job 纳入流水线，保证 schema 变更可回滚、可审计。
OceanBase 把分布式能力下沉到数据库内核，让「强一致 + 水平扩展 + 高可用」不再依赖外部中间件拼装。对于金融、交易、账务这类既要事务又要弹性的场景，它是国产数据库里值得认真评估的选项。先用 Docker 在本机跑通本文的集群与分区示例，再逐步把真实 schema 迁移过来，是风险最低的切入路径。
