OceanBase 从零开始：核心概念、上手路径，以及和 MySQL 的关键差异

如果你已经会 MySQL，第一次接触 OceanBase 时，最容易卡住的不是“SQL 怎么写”，而是：

它看起来很像 MySQL，为什么连接方式、资源模型、高可用和运维概念完全不是一回事？

本文面向零基础到 MySQL 初中级同学，用一条从概念到上手的路径讲清楚：

OceanBase 是什么
和 MySQL 在架构、租户、连接、兼容性上的核心差异
从连接、建库建表到基础 SQL 的最小实践
什么场景该把 OceanBase 当“更强的 MySQL”，什么场景不能这么想

说明：本文以 OceanBase 社区版（MySQL 模式） 为主。官方文档明确：社区版仅提供 MySQL 模式；企业版还支持 Oracle 模式。

一、先建立正确心智模型

1. MySQL 的常见心智模型

很多人对 MySQL 的默认理解是：

一台机器 / 一个 mysqld 实例
  └── 多个 database
       └── 多个 table

连接通常很直接：

mysql -h127.0.0.1 -P3306 -uroot -p

你连上的，基本就是“这个实例本身”。

2. OceanBase 的心智模型

OceanBase 更接近：

一个集群（Cluster）
  └── 多个节点（OBServer）
       └── 多个可用区（Zone）
  └── 多个租户（Tenant）   ← 应用视角下更像“数据库实例”
       └── 多个 database
            └── 多个 table / 分区

关键变化只有一句话：

在 OceanBase 里，应用通常不是“连一台 MySQL 机器”，而是“连某个租户”。

官方文档把租户定义为：集群内互相隔离的数据库“实例”。对应用来说，一个租户近似一个独立数据库实例；租户之间数据、权限、资源隔离。

二、OceanBase 是什么

OceanBase 是蚂蚁集团开源的分布式关系型数据库，基于 Paxos 类共识协议与分布式架构，提供高可用和水平扩展能力，可运行在普通服务器集群上。

官方强调的关键能力包括：

水平扩展
高可用（RPO=0、RTO 秒级恢复目标）
MySQL 兼容，便于迁移
HTAP（同一套系统同时服务事务与分析负载）
多租户资源隔离

你可以把“上手阶段”理解成两层：

层	你感受到的
SQL 层	很像 MySQL：`CREATE DATABASE` / `CREATE TABLE` / `SELECT`
系统层	更像分布式数据库：集群、Zone、租户、Unit、副本、OBProxy

三、和 MySQL 的核心差异总览

维度	MySQL（常见单机/主从）	OceanBase
基本部署单元	实例（mysqld）	集群 + 租户
应用连接对象	实例	租户（经直连或 OBProxy）
默认端口（常见）	`3306`	直连 `2881`，经 ODP/OBProxy 常见 `2883`
用户写法	`root`	`root@tenant` 或 `user@tenant#cluster`
扩展方式	垂直扩容 / 读写分离 / 分库分表	原生分区、多节点、副本扩展
高可用机制	主从复制、MGR 等	基于 Multi-Paxos 的多副本日志流
多业务隔离	多实例 / 多库 + 权限	原生多租户 + 资源池
存储引擎模型	InnoDB 等可插拔引擎	自研分布式存储与事务体系
SQL 兼容	原生 MySQL	MySQL 模式兼容 5.7/8.0 大部分能力，但非 100%
社区版模式	MySQL	仅 MySQL 模式

一句话：

MySQL 更像“一台关系库”；OceanBase 更像“一个可多租户的分布式数据库平台”。

四、架构差异：为什么它不像单机 MySQL

1. Shared-Nothing 集群

官方系统架构文档指出，OceanBase 常用无共享（Shared-Nothing）模式：

节点对等
每个节点都有自己的 SQL / 存储 / 事务能力
表可水平拆分为多个分区（Partition）
分区数据落在 Tablet，修改通过日志流（Log Stream）持久化
主从副本通过 Multi-Paxos 保持一致性

这意味着：

数据天然可分布到多节点
故障切换依赖副本选举，而不是简单“切到另一台 mysqld”
建表时的分区设计，会直接影响数据分布与扩展性

2. 多租户：最容易被 MySQL 同学忽略的概念

在 OceanBase 中：

集群初始化后会有系统租户 sys
sys 保存集群元数据，本身也是 MySQL 兼容模式租户
业务一般应在普通租户里建库建表，而不是把所有业务都堆在 sys

创建业务租户的典型顺序是：

Unit Config（资源规格）
  → Resource Pool（资源池）
    → Tenant（租户）

这和 MySQL 里“直接 CREATE DATABASE”完全不同。
MySQL 的 database 更像命名空间；OceanBase 的 tenant 更像独立实例边界。

3. OBProxy / ODP：应用如何“像访问单机库一样”访问分布式库

为了让应用尽量少感知分区和副本分布，OceanBase 提供 ODP（OceanBase Database Proxy，又称 OBProxy）：

应用通常连代理
代理把 SQL 路由到合适节点
对应用更接近“连一个入口地址”

这对应 MySQL 生态里的 proxy / 中间件角色，但在 OceanBase 里它更常作为标准访问路径出现。

五、连接差异：最容易踩坑的地方

1. Docker 体验环境（最简单）

快速体验可用官方镜像：

docker run -p 2881:2881 --name oceanbase-ce -e MODE=mini -d oceanbase/oceanbase-ce
docker logs oceanbase-ce | tail -1   # 期望 boot success!

连接示例：

# 系统租户 root
docker exec -it oceanbase-ce obclient -h127.0.0.1 -P2881 -uroot

# 或宿主机 mysql 客户端
mysql -h127.0.0.1 -P2881 -uroot
mysql -h127.0.0.1 -P2881 -uroot@test

2. 正式连接写法：用户名里有租户

官方文档给出两类常见连接：

直连 OBServer（默认端口常为 2881）

mysql -h<observer_ip> -P2881 -u用户名@租户名 -p

注意：

直连时 -u 应是 用户名@租户名
不要在直连用户名里带集群名，否则可能报错
普通租户直连时，目标节点上需要有该租户资源

通过 ODP/OBProxy（默认端口常为 2883）

mysql -h<odp_ip> -P2883 -u用户名@租户名#集群名 -p

用户名还可能写成：

集群名:租户名:用户名
集群名-租户名-用户名
集群名.租户名.用户名

这和 MySQL 的 root@'%' 完全不是同一套语义。

3. 客户端选择

可用 obclient
也可用 MySQL 客户端连接 MySQL 模式租户
官方文档提到当前支持的 MySQL 客户端版本包括 5.5 / 5.6 / 5.7（以你使用版本的文档为准）

六、从零上手：MySQL 同学 10 分钟路径

下面假设你已经能连上一个 MySQL 模式租户。

1. 看有哪些库

SHOW DATABASES;

体验环境里常见会看到 oceanbase、test、information_schema、mysql 等。

2. 创建业务库

CREATE DATABASE demo DEFAULT CHARACTER SET utf8mb4 READ WRITE;
USE demo;

这和 MySQL 非常像。

3. 建表、写入、查询

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(64) NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (id, name) VALUES
  (1, 'alice'),
  (2, 'bob');

SELECT id, name FROM users WHERE id = 1;
UPDATE users SET name = 'alice2' WHERE id = 1;
DELETE FROM users WHERE id = 2;

官方 MySQL 模式基础文档也覆盖了：

CREATE DATABASE / SHOW DATABASES
CREATE TABLE / SHOW TABLES / SHOW CREATE TABLE
ALTER TABLE
INSERT / UPDATE / DELETE / TRUNCATE
多表查询、聚合、EXPLAIN 等

4. 看建表细节时的“OceanBase 味道”

在 OceanBase 里执行：

SHOW CREATE TABLE users\G

你可能会看到比 MySQL 更“重”的表属性，例如副本数、压缩、Tablet 相关参数等。
这说明：SQL 表面兼容，元数据与存储参数并不等同于 InnoDB。

七、兼容性：像 MySQL，但不是 100% MySQL

官方《与 MySQL 兼容性对比》说明：

OceanBase 的 MySQL 模式兼容 MySQL 5.7/8.0 的绝大部分功能和语法；因架构差异或需求优先级，部分功能未支持。

1. 相似度高的部分

通常对应用最友好的部分：

常见数值 / 时间 / 字符 / JSON 等数据类型
SELECT / INSERT / UPDATE / DELETE
多表连接、子查询、聚合分组
存储过程、函数、触发器等大部分 PL 能力
information_schema、mysql 中的大量视图（但不是逐列完全等价）

因此：

很多基于 MySQL 协议的驱动可直接连
简单 CRUD 业务迁移门槛较低
你会有“这不就是 MySQL 吗”的错觉

2. 必须注意的差异

官方明确提到的差异方向包括：

类别	差异点
SQL 语法	例如不支持 `SELECT ... FOR SHARE ...`
TRUNCATE	不支持在事务处理与表锁定过程中操作
系统视图	不保证所有视图/列含义都与 MySQL 相同
存储引擎	不是 InnoDB 插件体系，而是自研分布式存储事务体系
优化器	执行计划与优化策略不同
分区 / 备份恢复	能力模型与操作路径不同
架构相关功能	因分布式架构，部分单机 MySQL 习惯不能照搬

3. 实战迁移建议

从 MySQL 迁到 OceanBase 时，不要只做“能不能连上”：

先验证协议层：驱动、连接池、ORM
再验证 SQL 层：慢 SQL、锁、事务边界、分页、HINT
再验证运维层：备份恢复、监控指标、扩缩容、租户资源
最后验证边界语法：冷门函数、系统表、复制相关特性、特定锁语法

一句话：

兼容的是“MySQL 使用体验”，不是“MySQL 内核实现”。

八、对象模型对比：database 相同，边界不同

MySQL

Instance
  └── Database
       └── Table / View / Procedure

权限、连接、资源，常常都围绕“实例 + 账号”展开。

OceanBase

Cluster
  └── Tenant（资源与权限边界更强）
       └── Database
            └── Table / Index / Procedure
  └── sys 租户（集群元数据）

对 MySQL 同学最实用的迁移记忆：

你在 MySQL 想做的事	在 OceanBase 更常见的对应
新建一个业务实例	新建一个业务租户
在实例里建库	在租户里 `CREATE DATABASE`
给业务分配 CPU/内存	调整 Unit Config / Resource Pool
连业务库	连 `user@tenant`
做高可用	规划 Zone / 副本 / 主备切换，而不是只配主从

九、一个最小对比实验（帮助真正理解差异）

实验 A：同一套 CRUD

在 OceanBase MySQL 模式租户执行：

CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4;
USE shop;

CREATE TABLE orders (
  order_id BIGINT PRIMARY KEY,
  user_id  BIGINT NOT NULL,
  amount   DECIMAL(10,2) NOT NULL,
  status   VARCHAR(16) NOT NULL
);

INSERT INTO orders VALUES
  (1001, 1, 19.90, 'PAID'),
  (1002, 2, 39.00, 'CREATED');

SELECT * FROM orders WHERE status = 'PAID';

你会发现：
如果只看 SQL，这和 MySQL 几乎没区别。

实验 B：连接串差异

MySQL：

mysql -h127.0.0.1 -P3306 -uroot -p shop

OceanBase 直连某租户：

mysql -h127.0.0.1 -P2881 -uroot@test -p shop

OceanBase 经 ODP：

mysql -h127.0.0.1 -P2883 -uroot@test#cluster_name -p shop

你会发现：
真正拉开差距的，是“你连到了哪里”和“资源边界在哪里”。

实验 C：多租户隔离

在 sys 中创建两个业务租户后：

root@tenant1 里建表
root@tenant2 里看不到那张表

官方多租户示例正是用这种方式证明：
租户之间资源、数据、权限隔离。

这比 MySQL 里“两个 database 互相授权”要更接近“两个实例”。

十、什么时候适合用 OceanBase，什么时候继续 MySQL

更适合考虑 OceanBase 的场景

需要水平扩展，单机 MySQL + 分库分表成本高
需要更强的金融级高可用与多副本一致性
希望一套系统兼顾 TP 与部分 AP
多业务要强隔离，但又想统一运维平台（多租户）
已有大量 MySQL 协议应用，希望降低改造成本

更适合继续 MySQL 的场景

单机或轻量业务，数据量和可用性要求不高
团队只熟悉传统 mysqld 运维，短期不想引入分布式复杂度
深度依赖某些 MySQL 专有行为 / 插件 / 生态工具且未验证兼容
本地开发只需要极轻量依赖（虽然也可用 OceanBase Docker，但 MySQL 更轻）

十一、学习路线建议

如果你是 MySQL 背景，建议按这个顺序学：

先跑起来：Docker / obd demo
先会连：user@tenant、2881 / 2883
先当 MySQL 用：建库建表 CRUD
再学租户与资源：Unit / Resource Pool / sys 与普通租户
再学分布式：分区、副本、Zone、OBProxy 路由
最后做迁移评估：兼容性清单 + 压测 + 备份恢复演练

配套阅读：

本站另一篇：OceanBase 多平台搭建教程
官方 MySQL 兼容性文档
官方系统架构与多租户文档

十二、速查对照表

主题	MySQL	OceanBase
默认连接	`root@host:3306`	`root@tenant@host:2881` 或经 ODP `2883`
业务隔离	database / 多实例	tenant
管理入口	实例管理员	常先登 `sys` 做集群与租户管理
扩展	加配 / 分库分表	分区 + 多节点 + 资源单元
高可用	复制拓扑	Multi-Paxos 多副本
SQL 习惯	原生 MySQL	高度兼容，但要做差异验证
社区版模式	MySQL	仅 MySQL 模式

总结

OceanBase 对 MySQL 同学并不“难在 SQL”，而难在换模型：

把“实例”理解升级成“集群 + 租户”
把“连上 mysqld”升级成“连上正确的租户入口”
把“兼容 MySQL”理解成“协议与常用 SQL 友好，不等于内核相同”
先用 CRUD 建立信心，再用租户、分区、副本理解它的分布式能力

掌握这四步后，你就不会再把 OceanBase 误当成“换了皮的 MySQL”，也能更准确判断它该用在什么地方。

参考资料

OceanBase 官方仓库 README（中英文，MySQL 兼容与快速开始）：https://github.com/oceanbase/oceanbase
OceanBase 官方文档：系统架构（oceanbase-doc / V4.3.5）
OceanBase 官方文档：与 MySQL 兼容性对比
OceanBase 官方文档：SQL 基础操作（MySQL 模式）
OceanBase 官方文档：体验多租户特性
OceanBase 官方文档：通过 MySQL 客户端连接 OceanBase 租户
OceanBase Docker 镜像：https://hub.docker.com/r/oceanbase/oceanbase-ce
OceanBase 中文文档中心：https://www.oceanbase.com/docs/oceanbase-database-cn