我和OceanBase集中式 滚了4个月回顾，MySQL兼容性的惊喜

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满  9群 为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

下载链接   https://fs80.cn/duykvo   

欢迎大家下载 本人和OB集中式老师 摸爬滚打 4个月产出的 OB 集中式兼容MySQL 报告

咱们接着上期说，4个月不断的测试，在兼容性中测试中，有一个点OB没有过，但他就应该不过，这是我测试中的一个惊喜。我们先说说测试中我们都测试了什么。

一、数据类型：5 种 MySQL 没有的类型，全是刚需 第一个让我感到"惊喜"的，是数据类型里 OceanBase 多出来的那 5 种类型。

我把 MySQL 和 OceanBase 的数据类型逐一比对了一遍。大部分类型完全一致——整数、浮点、定点、日期时间、JSON、ENUM、SET、布尔、空间数据，这些都 OK。差异点集中在"最大长度"上，OceanBase 给得更宽松一些。

但真正让我眼前一亮的是 OceanBase 多出的 5 种 MySQL 完全不支持的类型

其中向量类型和 RoaringBitmap 让我印象最深。向量类型直接服务于 AI 场景——你可以把 Embedding 结果直接存进 OceanBase，不需要再额外引入 Milvus 或 Pinecone。RoaringBitmap 适合去重统计——比如"过去 30 天每个用户每天活跃天数"，MySQL 需要 COUNT(DISTINCT) 跑几分钟，OceanBase 用 RoaringBitmap 做位图运算，秒级返回。

有一个需要注意的点：自增列（AUTO_INCREMENT）可能会跳号。OceanBase 内部为了提升高并发写入性能，采用了预分配 Cache 模式。如果数据库重启或者事务回滚，预分配的 ID 段会被丢弃，就会出现跳号。对绝大多数业务来说这不是问题（主键本来就不该依赖连续性），但如果你的业务有特殊要求，可以在建表时加 NO CACHE，代价是写入性能会下降。

二、DQL/DML：30 条测试，29 条直接过

这部分我写了 30 条测试 SQL，覆盖日常开发中用到的所有类型：基础查询、多条件、排序、分页、DISTINCT、GROUP BY、HAVING、JOIN（INNER/LEFT/RIGHT）、UNION、INSERT 单行/多行/SELECT、INSERT IGNORE、REPLACE INTO、UPDATE 单行/多列/条件、DELETE、事务提交/回滚、NULL 判断、CHECK 约束、自动更新时间戳、函数计算……

惊喜 JOIN + 子查询 + 聚合 + 分页一条龙 我特意写了一条"极端"测试：INNER JOIN 两张大表 + LEFT JOIN 第三张表 + GROUP BY + HAVING + 子查询 IN + LIMIT 分页。在 MySQL 上执行没问题，在 OceanBase 上——SQL 直接复制粘贴，结果集完全一致，响应时间还快了 15%（应该是 LSM-Tree 存储引擎的优势）。这让我松了一大口气——我们线上那些复杂的报表查询，迁移过来应该不会有问题。

惊喜 CHECK 约束原生支持 我建了一张表，加了 CHECK 约束：CONSTRAINT chk_user_age CHECK (age >= 0)。然后尝试插入 age=-5 的记录——OceanBase 直接报错拒绝。MySQL 5.7 不支持 CHECK 约束（虽然语法上能写但会被忽略），MySQL 8.0 支持。这一点 OceanBase 和 MySQL 8.0 行为一致，甚至更严格。

惊喜 自动更新时间戳 ON UPDATE updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP——INSERT 时 created_at 和 updated_at 相同，UPDATE 时 updated_at 自动刷新。这个特性 OceanBase 完全兼容，没有任何问题。

大惊喜 存储过程：基本兼容，一个 Collation 校验的意外 存储过程我写了 8 个测试用例覆盖创建、调用、IN/OUT/INOUT 参数、变量定义、IF/CASE/WHILE/LOOP、游标、异常处理、事务控制。大部分一次跑通。唯一让我蹲在屏幕前想了半小时的是存储过程 Collation 校验比 MySQL 严格 我在 MySQL 里写了一个带 IN 参数的存储过程，参数没指定 Collation，MySQL 自动隐式转换表的 Collation，正常运行。但在 OceanBase 里直接报错：ERROR 1267 (HY000): Illegal mix of collations (utf8mb4_0900_ai_ci,IMPLICIT), (utf8mb4_general_ci,IMPLICIT)

原因是 OceanBase 的 Collation 校验更严格——参数默认 Collation 和表的 Collation 不一致就不允许隐式转换。

修正方式：在参数上显式指定 Collation：IN p_dept VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci。改完之后 OceanBase 立刻通过。

坦白说，OceanBase 这个行为对开发者来说是"好事"——MySQL 的隐式转换是个隐性 bug 制造机，OceanBase 帮你把问题暴露出来了。但迁移时需要留意这种差异。

三、索引和分区：OceanBase 多出了 6 种 MySQL 没有的能力 基础的 B-Tree、唯一索引、前缀索引，OceanBase 和 MySQL 完全兼容。但 OceanBase 多出的 6 种索引能力，让我觉得 MySQL 在这方面确实不够用

全局索引特别值得说——在分布式场景下，MySQL 的分区表只能在分区内保证唯一性，跨分区的唯一约束没法做。OceanBase 的 GLOBAL INDEX 完美解决了这个问题，它会在全局范围内维护一个唯一索引，不管数据存在哪个分区，都能保证不重复。

四、日常运维的SQL能在OceanBase集中式上用吗？

最后测的是 DBA 最常问的——日常运维 SQL 能不能直接复用？

我选了 12 条最常用的 DBA 查询逐条测试。结论很清晰：11 条直接复用，1 条需要改写。

通过的 11 条包括：用户信息、权限查询、SHOW DATABASES/TABLES/CREATE、information_schema 下的 columns/key_column_usage/statistics、processlist、SHOW STATUS LIKE 'Threads%' 等。返回结果和 MySQL 完全一致，甚至在 SHOW GRANTS 里，OceanBase 的信息组织更清晰。

唯一需要改写的是 SHOW ENGINE INNODB STATUS——OceanBase 底层是 LSM-Tree，根本没有 InnoDB 引擎。要看对等的信息，需要改用 OceanBase 特有的 GVOB_TRANSACTION_PARTITION_REDO_LOG 看事务日志状态。

Binlog 兼容性方面，OceanBase 给出了两种方案：

obbinlog 组件：拉取 OceanBase 特有的 clog（Commit Log），转换成标准 MySQL Binlog V4 协议。下游 Canal、Flink CDC、Maxwell 这些工具不需要任何改动就能直接消费。这是最省事的迁移路径。

Flink CDC 直连：OceanBase 提供原生 oceanbase-cdc connector，Flink 里写几行配置就能把数据流式写到 ClickHouse/Kafka/ES，不需要部署中间件。

一个需要留意的细节：UPDATE_BEFORE 参数必须开启，否则 Flink 收不到更新前的旧值，流式计算会算错。大事务会把 OB-CDC 内存缓冲区挤爆——这个问题 MySQL Binlog 也有，不是 OceanBase 独有。

最后，我还和产品经理因为一个兼容性，争论了一下，MySQL 里你可以写 ALTER TABLE t ADD COLUMN c INT ALGORITHM=INPLACE LOCK=NONE 来显式控制 DDL 的锁行为。OceanBase 会自动选择最合适的锁策略，但不支持显式指定。如果你迁移过来的 SQL 里有这些子句，需要手动删掉——OceanBase 解析不了，会直接报错。

其实我觉得这挺好，而因为在测试报告上，我写上了这条语句OB不支持，而让产品经理找到我，告诉我新版本支持了，语法完全支持，但因为我的报告已经出了，所以我就没有改，所以这里说一句，新版本语法这个部分完全兼容了。