逆向工程表名乱码99%是连接层未设utf8mb4所致，因navicat元数据查询依赖character_set_client和character_set_results，若二者非utf8mb4，information_schema中中文表名会在传输时被错误转码，而普通查询因数据本身编码一致故显示正常。
逆向工程表名乱码，99% 是连接层没设对 utf8mb4，不是数据库本身问题
为什么逆向工程时表名就乱码，而普通查询正常？
Navicat 的「逆向工程」功能会先执行元数据查询（如 SELECT table_name FROM information_schema.tables），这些结果的编码完全依赖连接初始化时的 character_set_client 和 character_set_results。即使你查数据看着正常，只要这两项不是 utf8mb4，information_schema 里的中文表名、字段注释、COMMENT 就会在传输阶段被错误转码一次。
- 典型现象：建表时用了
COMMENT '用户ID'，逆向工程生成的 ER 图里显示成COMMENT 'Óû§ID' - 根本原因不是表结构存错了，而是 Navicat 拿元数据时用 latin1 解析了本该是 utf8mb4 的字节流
- MySQL 的
information_schema表本身不存字符集属性，它完全反射服务端当前连接的字符集上下文
检查并强制连接使用 utf8mb4 的三处关键位置
必须同时满足以下三点，逆向工程才能正确读取中文标识符：
- 右键连接 → 编辑连接 → 「高级」选项卡 → 勾选
Override default charset→ 下拉选utf8mb4（不是utf8） - 同一页面 → 找到「初始化命令」→ 填入
SET NAMES utf8mb4;（注意结尾分号不能少） - 确认连接字符串里没有冲突参数，比如旧版配置残留的
characterEncoding=utf8或useUnicode=true单独出现（它们不指定 mb4，等效于 latin1 fallback）
验证是否真正生效，别信“测试连接成功”
“测试连接”只校验账号密码和网络通路，不校验字符集。必须手动执行：
SHOW VARIABLES LIKE 'character\_set%';
重点盯住这三项值是否全为 utf8mb4：
character_set_clientcharacter_set_connectioncharacter_set_results
只要其中一项是 latin1 或 gbk，逆向工程必然乱码——哪怕你刚点过“确定”，也得回去重设并**完全退出 Navicat 再重开**。
OceanBase / PostgreSQL 用户特别注意租户与 client_encoding 绑定
OceanBase 的字符集是租户级的，PostgreSQL 的 client_encoding 是会话级的。如果逆向工程连的是 OceanBase 租户 A，但该租户实际配的是 utf8mb3，或者 PostgreSQL 连接串漏了 options=-c%20client_encoding%3DUTF8，那 Navicat 拿到的表名就是错的字节，后续怎么调客户端都没用。
这种情况下，SET NAMES utf8mb4 在 MySQL 兼容层可能被忽略，必须在连接字符串末尾硬编码参数，或直接改租户配置。
