Navicat 17逆向工程生成ER图的前提是数据库具备真实外键约束、正确驱动及足够权限；卡在“正在加载表结构”通常因INFORMATION_SCHEMA查询失败，需授权SELECT、启用show_compatibility_56、选用MySQL(Native)驱动，并手动精选核心表、确保InnoDB引擎与显式FOREIGN KEY存在。
Navicat 17 本身不分析“开源项目库”，它只逆向已有数据库的物理结构；所谓“分析复杂开源项目库”，本质是把该项目部署后的真实数据库导入 Navicat，再通过逆向工程还原其表关系——前提是项目用的是 MySQL/PostgreSQL/KingbaseES 等 Navicat 支持的数据库，且表结构完整、外键真实存在。
逆向前必须确认开源项目的数据库是否“可逆向”
很多开源项目（如 WordPress、Discourse、GitLab CE）虽用 PostgreSQL 或 MySQL，但默认安装脚本可能跳过外键约束，或使用 MyISAM 引擎，或靠应用层维护逻辑关系。这类库逆向出来只有孤立的表，连线全空。
- 运行
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db'（MySQL）或\dt+（psql），确认核心表引擎为InnoDB（MySQL）或有显式FOREIGN KEY定义（PostgreSQL） - 查
SHOW CREATE TABLE users输出里是否含CONSTRAINT `fk_users_role_id` FOREIGN KEY (`role_id`) REFERENCES `roles` (`id`)这类完整语句，而不是仅靠字段名相似（如user_id）推测 - 避开 ORM 自动建表但未启用外键迁移的项目（如 Django 默认
db_constraint=False），这类需手动补约束或改源码重迁移
连接与驱动选错会导致元数据丢失
Navicat 17 对不同数据库的元数据读取依赖底层驱动行为，尤其在开源项目多用较新版本时（如 PostgreSQL 15+、MySQL 8.0.32+），错误驱动会静默丢掉索引类型、外键注释甚至列默认值。
- MySQL 场景：必须选
MySQL (Native)驱动，禁用 ODBC 或 SSH 隧道未启用Keep Alive—— 否则INFORMATION_SCHEMA.KEY_COLUMN_USAGE查询失败，外键线全消失 - PostgreSQL 场景：逆向前先在 psql 中执行
SET search_path TO pg_catalog, public;，避免 Navicat 因扩展视图干扰误读pg_am.amname - KingbaseES 场景：仅支持 V8+，且需 Navicat Premium 17.3.0 及以上，旧版会把自定义域（
DROP DOMAIN email）字段识别为UNKNOWN
勾选表时别贪多，按模块分批逆向
开源项目库动辄上百张表（如 Magento 有 300+），Navicat 17 对每张表单独发 SHOW CREATE TABLE，全选会超时、卡死在“正在加载表结构”，或因内存不足崩溃。
- 先只勾选核心模块表：比如分析用户系统，只选
users、roles、permissions、user_profiles；分析订单流，只选orders、order_items、payments - 绝对取消勾选
Include views—— 开源项目常带同名视图（如user_summary表 +user_summary视图），Navicat 会当成两个实体，导致 ER 图连线错乱、字段重叠 - 跳过日志表（
logs_*）、归档表（archive_*）、搜索索引表（ts_*），它们通常无外键，纯增删查，加进来只拖慢速度
逆向后连线断开？不是 Navicat 画错了，是库里没真约束
ER 图里表之间没连线，90% 是因为数据库里根本没建 FOREIGN KEY，Navicat 17 不做任何推测，只读 INFORMATION_SCHEMA 或 pg_constraint 的显式定义。
- 验证方式：右键模型画布 →
Validate Model，它会直接列出缺失外键的字段对（如orders.user_id → users.id） - 临时补救：在 Navicat 中手动建关系线，但注意这只是绘图层操作，不会同步回数据库；若需持久化，得导出 SQL 后手工加
ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) - 长期建议：给开源项目提 PR，补全 DDL 中的外键定义 —— 不是所有项目都像 Laravel 的 migrations 那样默认带
$table->foreignId('user_id')->constrained()
真正难的从来不是点“开始逆向”，而是判断这个开源项目的数据库是否值得逆向：它有没有把关系落在 schema 上，还是全靠代码硬编码。后者即使强行连出线，也是一张假 ER 图。
