作为一个从 MySQL 生态过来的开发者，第一次接触 OceanBase 时，最直观的感受是“兼容 SQL，但骨子里是分布式”。如果只是把它当成一个更大的 MySQL 实例来用，很容易在后续开发和运维中踩坑。这篇文章总结了我在学习 OceanBase 过程中认为最关键的 5 个概念，希望能帮助同样刚入门的同学少走弯路。
第一个是租户（Tenant）。在 OceanBase 里，一个集群可以划分出多个租户，每个租户之间资源隔离，有独立的 CPU、内存、IO 和存储配额。你可以把它近似理解为 MySQL 里的“实例”，但租户更轻量，创建和销毁都很方便。对业务来说，不同业务线或者不同环境可以共用同一个物理集群，但通过租户实现逻辑隔离，这比传统的一库一实例模式要灵活得多。
第二个是 Zone。OceanBase 集群的数据节点会分布在一个或多个 Zone 上，一个 Zone 通常对应一个机房或一个可用区。OceanBase 默认会把数据做三副本，分别放在三个 Zone 中，这样即使一个机房挂了，数据仍然是高可用的。理解 Zone 的意义在于，你后续做扩缩容、故障演练、异地多活设计时，都是以 Zone 为基本单位来规划的。
第三个是分区（Partition）。OceanBase 采用 Shared-Nothing 架构，一张大表会被水平拆分成多个分区，分布在不同的 Observer 节点上。分区键的选择会直接影响查询性能和数据分布的均匀性。和 MySQL 的分区表不同，OceanBase 的分区是分布式的，天然具备水平扩展能力。设计表结构时，一定要结合业务查询模式来选分区键，避免热点。
第四个是 OBProxy。应用连接 OceanBase 时，通常不直接连 Observer，而是通过 OBProxy。它会根据 SQL 的租户、分区信息把请求路由到正确的节点上，对应用层屏蔽了底层的拓扑变化。也就是说，当你扩容或者某个节点故障时，连接串不需要改，OBProxy 会自动处理路由和容灾。
第五个是 clog 和基线数据。OceanBase 使用 LSM-Tree 存储引擎，数据分为基线数据和增量数据。基线数据是合并后的稳定数据，增量数据则以 clog 的形式记录。理解这个机制有助于你理解为什么 OceanBase 的写入性能高、为什么需要定期做合并（Major Freeze），以及为什么有时候查询会触发多次合并读取。
这 5 个概念搞懂了，再看 OceanBase 的官方文档或者做 POC 测试，基本就不会迷路。后续我计划写一篇实际部署踩坑记录，欢迎关注交流。
12 个赞
OceanBase 中最关键的 5 个概念：租户（实例）、Zone（机房）、分区（分区表）、OBProxy（代理）、clog 和基线数据。
9 个赞
总结的很到位，这些都是很重要的概念，也是学习OB最基础的，这些搞不懂，别的就别谈了
6 个赞
感谢分享，学习了
7 个赞
期待持续分享
5 个赞
有道理
3 个赞
good idea
1 个赞
确实
1 个赞
看看看看
2 个赞
MySQL 使用者刚上手 OB，容易忽略分布式底层逻辑，单纯依赖兼容模式。租户、Zone、分区、OBProxy、存储结构这五点确实是入门核心。不少迁移出问题，根源就是没理解分区键设计、副本部署与合并机制，照搬 MySQL 方案极易产生热点与性能隐患，非常适合准备迁移的同学参考。
1 个赞
感谢分享，学习了
1 个赞
定这么多， 不是真爱，就是AI。。。
1 个赞
学习下
逻辑清晰。