Navicat 连接 OceanBase MySQL 租户失败提示 unknown database 'information_schema'，根本原因是 OB 4.x 默认关闭 MySQL 兼容模式，需在服务端启用 ob_mysql_compatibility_mode；同时须正确配置字符集为 utf8mb4、时区为 '+00:00'，并确保使用 IPv4 地址 127.0.0.1 和端口 2881 连接。
Navicat 连接 OceanBase MySQL 租户失败，提示 unknown database 'information_schema'
这是 oceanbase 4.x 默认关闭 mysql 兼容模式的典型表现。navicat 启动时会主动查询 information_schema 获取元数据，但 ob 的 mysql 租户默认不暴露该库，除非显式启用兼容开关。
不要尝试在 Navicat 里“绕过”或“模拟”这个库——根本没用。必须从服务端打开兼容性：
- 最直接：在 Navicat 新建连接的「高级」页签中，勾选
Use SSL（即使你不用 SSL，勾选后 Navicat 会跳过部分元数据探测） - 更可控：在「连接」页签的「初始化命令」栏填入：
SET SESSION ob_mysql_compatibility_mode = ON; - 一劳永逸（需 SYS 权限）：连接成功后，在查询窗口执行：
ALTER SYSTEM SET ob_mysql_compatibility_mode = ON;
表显示为空、字段乱码或时间错位
本质是字符集和时区没对齐。OceanBase MySQL 租户默认用 utf8mb4 和 +00:00，但 Navicat 握手时可能按 latin1 解析，或读取本地时区（如 Asia/Shanghai），导致字符串截断、中文变问号、DATETIME 偏移 8 小时。
必须硬性指定，不能依赖自动协商：
- 在 Navicat 「连接」→「字符集」下拉框中，**必须选
utf8mb4**（不能留空，不能选 auto） - 在「高级」→「初始化命令」中添加两行：
SET NAMES utf8mb4;和SET time_zone = '+00:00'; - 若租户已存在，建议在租户级执行：
ALTER TENANT your_tenant_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
Connection refused 或 Can't connect to MySQL server
不是密码错，90% 是网络或协议层没对上。OceanBase 的 MySQL 协议端口（默认 2881）和 Oracle 协议端口（2883）严格分离；且 OB 不监听 IPv6 的 ::1，只响应 IPv4 的 127.0.0.1 或真实 IP。
检查顺序不能乱：
- 确认租户状态：执行
SELECT * FROM oceanbase.__all_tenant WHERE tenant_name = 'your_tenant';，确保status是ACTIVE - 确认监听地址：运行
netstat -tuln | grep 2881，看是否绑定在0.0.0.0:2881或具体 IP，而非仅127.0.0.1:2881 - Navicat 「主机」必须填
127.0.0.1（不要填localhost），端口填2881，数据库名填租户名（如mysql001），不是test或空
执行 DDL 报错 Not supported statement type
Navicat 自动生成的 DDL（比如带 ENGINE=InnoDB、AUTO_INCREMENT、PARTITION BY）在 OceanBase 中不被支持。OB 不是 MySQL 的复刻，它有自己的语法约束。
别指望 Navicat 的“生成 SQL”能直接跑通：
- 删掉所有
ENGINE=...、AUTO_INCREMENT、COMMENT='...'（除非租户开启ob_enable_comment）、KEY定义中的冗余选项 - 分区表必须用 OB 原生语法重写，例如改用
PARTITION BY KEY+PARTITIONS N - 连接前务必关闭 Navicat 的「自动提交」（在「连接」页签底部），否则单条 DDL 失败会导致整个事务卡住
真正麻烦的不是连不上，而是连上了却误以为“一切正常”，结果在导出表结构、同步数据、生成迁移脚本时突然崩在某个隐式兼容点上——这些地方没有报错提示，只有行为偏差。
