能，但前提是数据库用户权限、字符集和外键约束三者匹配；否则易卡在“正在加载表结构”或生成空图。Navicat依赖information_schema等系统视图读取元数据，权限不足则无法建模，且只识别真实定义的约束，不推断逻辑关联。
能，但前提是数据库用户权限、字符集和外键约束这三件事对得上；否则大概率卡在“正在加载表结构”或生成空图。
逆向工程前必须确认的三个权限点
Navicat 不是靠猜，而是靠查 information_schema 或 pg_catalog 获取元数据。如果连这些系统视图都读不到，就根本不会开始建模。
- MySQL 8.0+ 用户必须显式授予
SELECT权限给information_schema.TABLES、COLUMNS、KEY_COLUMN_USAGE——只给业务库权限没用 - PostgreSQL 用户需有
USAGE ON SCHEMA pg_catalog和SELECT ON TABLE pg_tables，否则“No tables found”是常态 - KingbaseES（V8+）同理，要确保用户对
sys_tables、sys_columns等系统表有读权限，且 Navicat 版本 ≥17.3
为什么外键线不连、主键变普通字段
Navicat 只认真实存在的约束定义，不认命名约定、不推断索引、不脑补逻辑关联。
- 执行
SHOW CREATE TABLE users，确认输出里有CONSTRAINT `fk_users_role_id` FOREIGN KEY (`role_id`) REFERENCES `roles` (`id`)这类完整语句 - MySQL 中若用
ALTER TABLE ADD COLUMN user_id INT但漏了ADD CONSTRAINT，Navicat 就看不到外键 - PostgreSQL 外键若为
NOT VALID（比如迁移时跳过验证），Navicat 默认忽略——需先ALTER TABLE ... VALIDATE CONSTRAINT - 复合外键如
(a, b) REFERENCES t2(c, d)在 Navicat 16 以下版本识别不稳定，建议先简化或手动连线
大库、分表、乱码场景下的实操避坑
接手旧项目常遇到 500+ 表、utf8mb4_bin 排序、日志分表等现实问题，直接“Select All”会卡死或导出错乱。
- 表数超 300 张时，进逆向工程窗口后别点“Select All”，手动展开 schema，只勾选核心业务表（如
users、orders、products） - SQL 文件头部若含
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin，建库时务必在 Navicat 新建连接页同步选对，否则中文注释可能乱码、排序异常 - 日志表、历史归档表（如
log_202501、archive_orders_2024）建议取消勾选“Include system tables”和“Include views”，避免干扰主模型 - 导出 PNG/SVG 前，先在 Navicat「工具 → 选项 → 模型 → 字体」中设为
Microsoft YaHei或SimSun，再点右上角“适应窗口”并缩放至 120%，否则字段名糊成一片
模型建好后别急着导出，先做两件事
逆向出来的模型只是起点，不是终点。旧项目往往字段无注释、关系靠命名、表名缩写不统一，这时模型的编辑能力比生成能力更重要。
- 右键单张表 →「编辑表」→ 关闭“自动排列字段”，手动拖窄字段区高度，避免 20+ 字段堆叠重叠
- 用右侧「层（Layer）」功能分区：比如新建 “租户相关”、“认证模块”、“支付链路” 三层，把对应表拖进去，比全屏散列清晰得多
- 字段没注释？双击字段 → 在「备注」栏手写说明（如
status：“0-待审核 1-已通过 9-已拒绝”），保存后鼠标悬停即可见
真正容易被忽略的是：逆向工程生成的模型，本身不包含触发器、存储过程、函数逻辑，也不解析视图定义里的嵌套查询。如果旧项目重度依赖这些，光靠 ER 图远远不够——得配合 SHOW CREATE VIEW 和源码交叉验证。
