OceanBase学习

OceanBase（OB）是蚂蚁集团完全自研的原生分布式关系型数据库，2010年诞生，支撑支付宝/双11核心交易，金融级高可用，同时兼容 MySQL 与 Oracle 两种模式，是国产分布式数据库的标杆。

一、核心定位（一句话懂差异）

Oracle：集中式商用数据库，闭源，高端硬件，强事务，金融传统核心。
达梦DM8：集中式（可选共享存储集群），Oracle 高度兼容，政务/国企信创首选。
OceanBase：原生分布式，MySQL/Oracle 双兼容，普通x86服务器，水平扩展，金融互联网核心/海量数据。

二、架构与核心特性（重点）

1. 原生分布式（和达梦/Oracle 最大区别）

无共享（Shared-Nothing）：数据打散到多节点，无需分库分表中间件，应用透明。
Paxos 多副本强一致：默认3副本，自动选主，故障秒级切换，数据零丢失。
三地五中心容灾：城市级故障无损恢复，金融级高可用。
水平扩展：加机器即加算力，单集群可超1500节点。

2. 双兼容模式（MySQL + Oracle）

MySQL 模式：完全兼容 MySQL 5.7/8.0 协议与语法，迁移成本极低。
Oracle 模式：高度兼容 Oracle 11g/12c，支持 PL/SQL、存储过程、序列、rownum 分页、函数等，达梦有的 Oracle 兼容 OB 基本都有，且分布式能力更强。

3. 性能与存储

TPC-C 世界纪录：7.07亿 tpmC，远超传统集中式库。
LSM-Tree 存储引擎：高压缩比（5:1~10:1），存储成本低，读写性能优。
HTAP 混合负载：一套引擎同时跑交易（OLTP）+ 分析（OLAP）。

4. 多租户（云原生）

单集群划多个租户，资源隔离，天然支持 DBaaS，适合政务云/金融云。

三、OceanBase vs 达梦 DM8（信创选型关键）

1. 架构

达梦：集中式（单节点/共享存储集群DMDSC），类似 Oracle RAC。
OceanBase：原生分布式（无共享），水平扩展，数据量/并发远超达梦。

2. 兼容性

达梦：Oracle 兼容度更高（约95%），PL/SQL、存储过程、触发器几乎无缝迁移，政务Oracle迁移首选。
OceanBase：Oracle 兼容度约85%~90%，核心SQL/函数/对象兼容，复杂包/高级PL/SQL需微调；同时支持MySQL模式，双生态更灵活。

3. 适用场景

达梦：政务、国企、能源、军工，中小规模核心系统（≤10TB），Oracle迁移，信创合规优先。
OceanBase：银行/保险核心、互联网高并发、海量数据（≥10TB）、异地多活/城市级容灾、MySQL/Oracle混合迁移。

4. 生态与成本

达梦：国产CPU（飞腾/龙芯）+ 麒麟OS 适配深，政务工具链完善，** license+服务成本适中**。
OceanBase：x86/鲲鹏为主，社区版免费，企业版按集群授权，硬件成本低（普通x86），金融/互联网生态强。

四、OceanBase vs Oracle（迁移要点）

相同点

完全 ACID，强事务，高可用。
支持复杂SQL、存储过程、函数、触发器、视图、序列。
支持行级锁、事务隔离级别、物化视图。

不同点（迁移必改）

架构：Oracle 集中式/共享存储RAC；OB 分布式无共享，应用无需改分库分表。
语法差异（高频）
- Oracle：wm_concat → OB：listagg（同达梦）。
- Oracle：dbms_job → OB：用内置定时或业务层Quartz。
- Oracle：connect by 层级查询 → OB：支持但需微调。
驱动与连接串
- Oracle：ojdbc，jdbc:oracle:thin:@ip:1521:orcl。
- OB：oceanbase-jdbc，jdbc:oceanbase://ip:2881/库名（Oracle模式）。
高级特性：Oracle 独有 dbms_java、部分高级 dbms_* 包、RAC 专属管理视图 → OB 需替换或用业务代码实现。

五、信创组合建议（直接抄）

1. 金融核心（高可用+分布式）

CPU：海光 C86 / 鲲鹏 920
OS：欧拉 openEuler / 麒麟 V11
数据库：OceanBase 企业版（Oracle模式）
中间件：宝兰德 BES / 东方通 TongWeb

2. 政务大规模数据（Oracle迁移+分布式）

CPU：飞腾 FT-2000+
OS：银河麒麟 V10
数据库：OceanBase（Oracle模式） 或达梦 DM8（中小数据）
中间件：东方通 TongWeb

六、总结

达梦：Oracle 最佳集中式平替，政务信创首选，中小规模、Oracle 语法无缝迁移。
OceanBase：原生分布式+双兼容，金融级高可用，海量数据/高并发/异地容灾首选，MySQL/Oracle 混合场景迁移成本低。

下面我用最直白、一步到位的方式讲清楚：OceanBase 怎么装、怎么连、怎么建库建表、怎么用 Oracle/MySQL 模式、常用命令和迁移要点。你照着做就能跑通。

一、核心概念（先懂再用）

OceanBase（OB）：蚂蚁集团自研原生分布式数据库，支持 MySQL 模式 + Oracle 模式。
端口：默认 2881（数据库）、2882（内部通信）。
租户：OB 是多租户架构，sys 租户=管理集群，业务要建独立租户（如 tenant1）。
模式：
- MySQL 模式：兼容 MySQL 5.7/8.0，语法基本一样。
- Oracle 模式：高度兼容 Oracle 11g/12c，支持 PL/SQL、存储过程、序列、rownum 等。

二、快速安装（3种方式，选一种）

方式1：Docker 1分钟体验（推荐新手）

1# 拉镜像并启动（mini模式，资源占用小）
2docker run -p 2881:2881 --name ob -e MODE=MINI -e OB_TENANT_PASSWORD=123456 -d quay.io/oceanbase/oceanbase-ce
3
4# 连接（密码123456）
5mysql -h127.0.0.1 -P2881 -uroot@sys -p123456
6

方式2：OBD 单机部署（官方工具，生产/测试都可用）

1# 1. 安装 OBD（CentOS）
2sudo yum install -y yum-utils
3sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
4sudo yum install -y ob-deploy
5
6# 2. 一键部署 demo（3节点集群，本地模拟）
7obd demo
8
9# 3. 连接
10obclient -uroot@sys -h127.0.0.1 -P2881 -p
11

方式3：物理机/服务器生产部署

系统：CentOS 7.9+/Ubuntu 20.04+
最低配置：2核4G + 20G SSD
关闭防火墙/SELinux，配置 NTP 时钟同步
用 OBD 或图形化界面部署（参考官方文档）

三、连接数据库（2种客户端）

1）用 MySQL 客户端（最方便）

1# 连接 sys 租户（管理）
2mysql -h127.0.0.1 -P2881 -uroot@sys -p
3
4# 连接业务租户（如 tenant1）
5mysql -h127.0.0.1 -P2881 -uroot@tenant1 -p
6

2）用 OB 专用客户端 obclient

1obclient -uroot@sys -h127.0.0.1 -P2881 -p
2

连接成功提示符：

1Welcome to the OceanBase.  Commands end with ; or \g.
2mysql>
3

四、基础操作（建租户→建库→建表→读写）

1）创建业务租户（关键！不能用 sys 跑业务）

1-- 登录 sys 租户执行
2CREATE TENANT IF NOT EXISTS tenant1 
3PRIMARY_ZONE='zone1' 
4REPLICA_NUM=3 
5CHARSET=utf8mb4 
6COLLATE=utf8mb4_unicode_ci;
7
8-- 设置租户密码（Oracle/MySQL 模式通用）
9ALTER USER root@tenant1 IDENTIFIED BY '123456';
10

2）切换到租户，创建数据库

1-- 连接 tenant1 后
2CREATE DATABASE testdb;
3USE testdb;
4

3）建表（MySQL 模式）

1CREATE TABLE user (
2  id INT PRIMARY KEY AUTO_INCREMENT,
3  name VARCHAR(50) NOT NULL,
4  age INT
5);
6
7INSERT INTO user (name,age) VALUES ('张三',20);
8SELECT * FROM user;
9

4）Oracle 模式使用（重点）

1-- 1. 租户设置为 Oracle 模式（sys 租户执行）
2ALTER TENANT tenant1 SET ob_compatibility_mode=oracle;
3
4-- 2. 连接 tenant1，语法和 Oracle 几乎一样
5CREATE TABLE emp (
6  empno NUMBER(4) PRIMARY KEY,
7  ename VARCHAR2(10),
8  sal NUMBER(7,2)
9);
10
11INSERT INTO emp VALUES (1,'李四',5000);
12SELECT * FROM emp WHERE rownum<=1; -- Oracle 分页
13

五、常用管理命令（必记）

集群状态

1SELECT * FROM oceanbase.__all_server; -- 查看节点
2SELECT * FROM oceanbase.__all_tenant; -- 查看租户
3

租户管理

1ALTER TENANT tenant1 SET ob_compatibility_mode=mysql; -- 切回MySQL模式
2DROP TENANT tenant1; -- 删除租户
3

用户权限

1CREATE USER appuser@tenant1 IDENTIFIED BY '123456';
2GRANT ALL ON testdb.* TO appuser@tenant1;
3

六、应用连接（Java/Go/Python）

Java（JDBC）

1# MySQL 模式
2url=jdbc:mysql://127.0.0.1:2881/testdb?useSSL=false
3driver=com.mysql.cj.jdbc.Driver
4
5# Oracle 模式
6url=jdbc:oceanbase://127.0.0.1:2881/testdb?useSSL=false
7driver=com.oceanbase.jdbc.Driver
8

Python

1import mysql.connector
2conn=mysql.connector.connect(host='127.0.0.1', port=2881, user='root@tenant1', password='123456', database='testdb')
3

七、Oracle 迁移 OB 要点（高频差异）

驱动：ojdbc → oceanbase-jdbc（Oracle模式）
语法兼容：
- wm_concat → listagg
- connect by → 支持但需微调
- dbms_job → 用内置定时或业务层Quartz
对象迁移：表、视图、存储过程、函数、序列大部分直接可用，复杂包需少量修改。

八、什么时候用 OB？

✅ 替代 Oracle（金融/政务核心，分布式+双兼容）
✅ MySQL 业务数据超10TB/高并发，不想分库分表
✅ 需要异地多活/三地五中心容灾
✅ 信创国产化（适配海光/鲲鹏/麒麟OS）

OceanBase 怎么处理「分库分表」？

核心一句话：
OceanBase 原生内置分布式分片，业务层完全不需要 MyCat、Sharding-JDBC 做分库分表，天然自动分片。

一、传统 MySQL 痛点（你原来的做法）

MySQL 单机容量/性能上限低，海量数据必须：

中间件：Sharding-JDBC、MyCat、ShardingSphere
手动：水平分表、垂直分库、按月分表
痛点：代码侵入、改造大、跨库联表、分布式事务坑多

二、OceanBase 核心：原生分布式、自动分片

OB 架构：

集群多节点
数据按分区键自动打散到不同节点
上层业务 单库单表写法，不用改分片代码

关键概念

分区（Partition）
OB 底层把一张大表自动拆成很多小分区，分散在不同服务器。
副本
默认3副本，高可用、故障自动转移。
分区方式（就是分库分表的替代品）

三、OceanBase 三种分片方式（对标分库分表）

1. 哈希分区 → 对标【水平分表/用户ID分片】

最常用，替代 user_id % 16 这种分片

1-- Oracle 模式 / MySQL 模式通用
2CREATE TABLE order_info (
3    order_id NUMBER,
4    user_id NUMBER,
5    create_time DATE
6)
7PARTITION BY HASH(user_id)
8PARTITIONS 32; -- 拆32个分区，均匀打散多节点
9

效果：

相同 user_id 落在同一个分区
多节点并行写入，解决大并发
业务 select * from order_info where user_id=1001 自动路由到对应节点

2. 范围分区 → 对标【按时间分表、按月分表】

完美替代每月一张表、历史归档

1CREATE TABLE order_info (
2    order_id NUMBER,
3    create_time DATE
4)
5PARTITION BY RANGE(create_time) (
6    PARTITION p202601 VALUES LESS THAN(TO_DATE('2026-02-01','YYYY-MM-DD')),
7    PARTITION p202602 VALUES LESS THAN(TO_DATE('2026-03-01')),
8    PARTITION pmax VALUES LESS THAN(MAXVALUE)
9);
10

优势：

删历史数据：直接 drop partition 秒级删除
按时间查询只扫描对应分区，性能极高

3. 列表分区 → 对标【按地区/渠道分片】

按城市、渠道、业务线打散数据

四、对比：Sharding-JDBC vs OceanBase

项目	传统MySQL+Sharding	OceanBase 原生
分片代码	侵入业务、需改代码	零代码、单表写法
跨分区join	极难、坑多	原生支持分布式Join
分布式事务	弱一致、容易出问题	全局强一致
扩容	需手动迁移分片	加机器自动均衡数据
运维	复杂、分片规则难维护	库内统一管理

五、OB 特殊能力：全局索引

普通分库分表：
跨分片字段查询非常慢（比如按手机号查订单）

OceanBase 支持：

本地索引（分区内）
全局索引（跨分区全局查询）
不用冗余、不用中间件，原生解决。

六、什么时候完全抛弃分库分表？

只要你用 OceanBase：

单表数据 亿级、十亿级 不用分表
高并发订单、流水、日志表直接单表跑
定时按月分表、归档用「范围分区」替代
用户维度海量数据用「哈希分区」

七、极简总结

OceanBase 自带分库分表能力，不需要 Sharding 中间件
底层通过 哈希/范围/列表分区 自动拆分数据
业务层还是 单库单表写法，无侵入
分布式事务、跨节点查询、扩容迁移全部数据库层搞定
是替代 MySQL 分库分表架构的国产分布式数据库最优解

OceanBase 分库分表（分区）+ 跨分区查询完整实操

先定核心结论：
OB 不用 Sharding-JDBC/MyCat 中间件
底层靠「分区 = 原生分表」实现，业务还是单表SQL，自动路由、跨分区直接查。

一、OB 里的「分库分表」对应关系

传统MySQL：
分库 + 分表 + 分片中间件
OceanBase：
租户=大库 → Database=业务库 → 表分区=自动分表
✅ 只需要做表分区，就是原生分库分表

三种主流分区（对应业务场景）

HASH分区：用户ID、商户ID → 水平分片
RANGE范围分区：时间、月份 → 按月/按天分表
LIST列表分区：地区、渠道、业务线

二、场景1：HASH分片（用户ID分表）+ 查询

1.建表（按user_id哈希分片，等效分成32张子表）

1-- Oracle模式 语法
2CREATE TABLE tb_order
3(
4    order_id    NUMBER,
5    user_id     NUMBER,
6    amount      NUMBER(10,2),
7    create_time DATE
8)
9-- 按user_id哈希分片
10PARTITION BY HASH(user_id)
11PARTITIONS 32;
12

2.单分区精准查询（自动路由，只查单个分片）

1-- 条件带分区键 user_id，OB自动定位到对应分区，性能最高
2SELECT * FROM tb_order WHERE user_id = 10086;
3

3.跨分区批量查询（直接写SQL，不用改）

1-- 跨多个哈希分区，OB底层自动聚合
2SELECT * FROM tb_order WHERE user_id IN (10086,10087,10088);
3

三、场景2：RANGE时间分片（按月分表）+ 查询

最常用：订单、日志、流水按月分表

1.建表按月分区

1CREATE TABLE tb_order
2(
3    order_id    NUMBER,
4    user_id     NUMBER,
5    create_time DATE
6)
7PARTITION BY RANGE (create_time)
8(
9    PARTITION p202601 VALUES LESS THAN (TO_DATE('2026-02-01','YYYY-MM-DD')),
10    PARTITION p202602 VALUES LESS THAN (TO_DATE('2026-03-01','YYYY-MM-DD')),
11    PARTITION p202603 VALUES LESS THAN (TO_DATE('2026-04-01','YYYY-MM-DD')),
12    PARTITION p_max   VALUES LESS THAN (MAXVALUE)
13);
14

2.查单个月（只扫描一个分区，极快）

1SELECT * 
2FROM tb_order 
3WHERE create_time >= TO_DATE('2026-03-01','YYYY-MM-DD')
4  AND create_time <  TO_DATE('2026-04-01','YYYY-MM-DD');
5

3.跨月份查询（自动跨分区合并结果）

1-- 跨2、3月，业务SQL完全不变
2SELECT * 
3FROM tb_order 
4WHERE create_time >= TO_DATE('2026-02-01','YYYY-MM-DD');
5

4.直接指定分区查询（运维/统计用）

1-- 强制只查202603分区
2SELECT * FROM tb_order PARTITION(p202603);
3

四、关键：非分区键查询怎么办？

比如：

按 order_id、手机号、订单号查询（不是分区键）

两种方案

本地索引
会扫描全部分区，数据量大较慢
OB全局索引（推荐）
给非分区键建全局索引，跨分区也能秒查

1-- 建立全局索引，非分区键快速查询
2CREATE GLOBAL INDEX idx_order_id ON tb_order(order_id);
3

建好后：

1-- 非分区键，依然高性能
2SELECT * FROM tb_order WHERE order_id = 9999;
3

五、跨分区 JOIN、聚合（原生支持）

1.跨分片联表查询

1SELECT a.*,b.name 
2FROM tb_order a
3LEFT JOIN tb_user b ON a.user_id = b.user_id
4WHERE a.create_time >= SYSDATE - 3;
5

✅ 不用中间件、不用手动关联子表，OB 自动跨节点计算

2.跨分区分组/统计

1SELECT user_id,COUNT(*) 
2FROM tb_order 
3WHERE create_time >= SYSDATE - 7
4GROUP BY user_id;
5

六、和Sharding-JDBC 最大区别

操作	Sharding+MySQL	OceanBase
分片规则	代码/配置文件写死	数据库建表时定义
单表查询	路由复杂	自动路由
跨分片查询	坑多、限制多	原生支持
跨库Join	基本不推荐	原生支持
扩容	手动迁移数据	加节点自动均衡
业务代码	大量改造	零改造，单表写法

七、开发使用规范（必记）

核心大表必须指定分区（HASH/RANGE）
查询尽量带上分区键，走分区裁剪，性能最高
非分区键高频查询，建立全局索引
禁止无脑 select * 不带条件，会扫描全部分区
历史数据清理：ALTER TABLE xxx DROP PARTITION 分区名 秒级删除

八、一句话总结

OB 的分区 = 替代传统分库分表
业务永远写单表SQL，不需要感知分片
带分区键：精准单分区查询
不带分区键：自动跨分区聚合
非分区键慢查询 → 加全局索引解决

OceanBase 分布式事务完整原理+实操（分库分表场景）

先给核心结论：

OceanBase 不需要 Sharding-JDBC、不需要Seata
底层原生支持 分布式事务、跨分区事务、跨节点事务
基于 两阶段提交+Paxos强一致，默认ACID，数据不丢、不脏写
你眼里的「分库分表」，在OB里就是分区，跨分区=天然分布式事务

一、先搞懂：OB 哪些场景会触发分布式事务

OB 一张大表拆成几十个分区，分散在不同机器：

同一张表、跨分区修改（比如user_id=1 和 user_id=100 在不同分区）
多张表、不同分区/不同节点 同时增删改
跨租户、跨库 操作
以上全部自动进入 OB 分布式事务

👉 传统MySQL+Sharding：
需要手动引入 Seata/TCC/XA，代码埋点、补偿、回滚特别麻烦。

👉 OceanBase：
完全无感，业务代码还是普通 begin/commit/rollback。

二、OB 分布式事务底层机制（极简大白话）

1. 核心协议

采用 自研2PC（两阶段提交）+ Paxos 多副本
全局事务号、全局快照、分布式MVCC

2. 两阶段流程

阶段1 Prepare
所有涉及的分区/节点预提交、锁资源、日志落地
阶段2 Commit/Rollback
- 全部Prepare成功 → 统一提交
- 任意一个失败 → 全体自动回滚

3. 隔离级别

支持：

Read Committed
Repeatable Read（默认）
完全满足金融、政务核心业务。

三、三种「分库分表」事务场景实操演示

下面语法 Oracle/MySQL模式通用，直接能用

场景1：同一张表跨分区事务（最常见）

订单表按 user_id HASH分区，两个用户在不同分片：

1-- 开启事务
2BEGIN;
3
4-- 操作分区A
5UPDATE tb_order SET amount=100 WHERE user_id=1001;
6
7-- 操作分区B（跨分区，自动触发分布式事务）
8UPDATE tb_order SET amount=200 WHERE user_id=2002;
9
10-- 统一提交
11COMMIT;
12

两条SQL落在不同节点
OB自动2PC，要么全部成功，要么全部回滚
业务代码零改动

场景2：两张不同大表跨表事务

订单表 + 账户表，都是分区表、分散节点：

1BEGIN;
2-- 扣余额
3UPDATE tb_account SET balance=balance-100 WHERE user_id=1001;
4-- 生成订单
5INSERT INTO tb_order(...) VALUES(...);
6COMMIT;
7

✅ 跨表+跨节点，原生分布式事务保证原子性

场景3：异常自动回滚

1BEGIN;
2UPDATE tb_account SET balance=balance-100 WHERE user_id=1001;
3-- 故意写一条报错SQL
4INSERT INTO tb_order VALUES(null);
5COMMIT;
6

👉 报错后：
OB 自动触发全局回滚，上一步扣钱全部撤销，不会超卖、不会脏数据。

四、对比：Sharding-JDBC + Seata VS OceanBase

能力	MySQL+Sharding+Seata	OceanBase 原生
跨分片事务	弱一致、TCC硬编码、补偿复杂	强一致、原生2PC
代码侵入	高、需注解、undo日志	0侵入，原生SQL
事务成功率	依赖框架+人工编码	数据库内核保障
性能损耗	高	优化版2PC，损耗极低
死锁/锁超时	问题多	分布式锁机制成熟
适配分表	中间件配置分片规则	建表分区即可

五、OceanBase 分布式事务开发规范（避坑）

1. 最佳实践（性能最好）

同一业务尽量分区键一致
比如：订单、账单、流水都用 user_id 作为分区键
同用户操作落在同一个分区，走本地事务，性能最高

2. 避免大跨度分布式事务

不要在一个事务里操作几十上百个分区
批量拆分、控制事务粒度

3. 锁与超时

OB 自带：

分布式行锁
事务超时自动回滚参数

1# 可调整事务超时时间
2ob_trx_timeout = 600000
3

4. 不推荐

不用手写XA、不用TCC、不用本地消息表，完全没必要。

六、极端故障场景（生产放心）

提交中某节点宕机
剩余节点等待恢复后，自动补齐提交/回滚，数据一致
机房断电、网络分裂
Paxos多数派机制，保证数据不分裂、不脏写
长期未提交事务
自动超时回滚，避免死锁和资源堆积

七、一句话终极总结

OceanBase 的分区 = 替代传统分库分表
跨分区、跨节点、跨表修改，自动走原生分布式事务
不需要 Sharding、不需要 Seata、不需要TCC、不需要补偿
业务只需要正常写 begin / commit / rollback
金融级强一致，是国产分布式里事务最强的数据库之一

《OceanBase学习》是转载文章，点击查看原文。