navicat物理模型创建无唯一路径，需据起点选择操作：从空白建模须选准数据库类型与版本；逆向工程需防精度丢失与视图解析失败；逻辑模型转换不继承外键索引；多表导入须处理命名冲突与循环依赖。
navicat data modeler 创建物理模型没有“唯一正确路径”，关键看你是从零开始、已有数据库，还是已有逻辑/概念模型——不同起点对应不同操作链路，选错会多走弯路甚至丢失元数据。
从空白新建物理模型：选对数据库类型和版本是前提
新建物理模型不是直接点“新建”就完事。文件 → 新建模型 后弹出的窗口里，“模型类型”必须选 物理，但更关键的是“数据库”和“版本”下拉框——这里选错会导致后续生成的 DDL 语法不兼容（比如选了 MySQL 8.0 却给 MySQL 5.7 用，JSON 类型或窗口函数会报错），索引选项卡里的参数（如前缀长度、全文索引支持）也会跟着变。
- 若目标库是 PostgreSQL 15，就选
PostgreSQL+15，别选14或泛用的通用 - Oracle 用户注意区分
Oracle和Oracle Cloud，后者默认启用 JSON 支持和自动分区策略 - 选完立刻点
确定，不要跳过——这个选择会固化到模型文件头，后期无法在 UI 中修改，只能导出再手动改 XML
从现有数据库逆向工程：避免字段精度丢失和视图解析失败
右键数据库/模式 → 逆向模式到模型 是最常用方式，但它默认跳过某些对象。常见问题包括：TINYINT(1) 被转成 BOOLEAN（MySQL）、NUMERIC(p,s) 的精度被截断、视图因依赖未导入的表而显示为空白。
- 执行前先确认连接权限：需要
SELECT权限读取information_schema，以及SHOW CREATE VIEW（MySQL）或pg_get_viewdef()（PostgreSQL）权限 - 勾选
包含注释和包含约束名，否则外键名变成系统自动生成的FK_123456，同步回库时难以定位 - 遇到视图解析失败，不要重试，先在原库执行
SHOW CREATE VIEW view_name看是否含子查询或临时表——Navicat 不解析嵌套 SELECT，这类视图需手动补全
从逻辑模型转换：主键和外键关系不会自动继承
右键逻辑模型 → 转换模型为物理模型 看似一步到位，但实际只复制表结构和字段，所有外键约束、索引定义、存储引擎/表空间设置全部丢失。这不是 Bug，是设计使然——逻辑模型不关心物理实现细节。
- 转换后必须逐个打开表的
表设计器，在外键选项卡里手动添加关联，否则模型里没连线，导出 SQL 也不含FOREIGN KEY -
索引选项卡里要重新指定UNIQUE、FULLTEXT或组合索引字段顺序，逻辑模型里的“候选键”不会自动转成唯一索引 - 如果逻辑模型用了抽象类型（如
Amount、Timestamp），转换后字段类型会变成数据库默认映射（如DECIMAL(10,2)或TIMESTAMP），需人工核对是否符合业务精度要求
导入多个表时：命名冲突和循环依赖要人工干预
在“对象”窗格中多选表 → 右键 逆向表到模型 很方便，但 Navicat 不做依赖排序。如果表 A 外键引用表 B，而 B 没被选中，A 的外键字段会变成普通字段，图标上不显示锁形标识；更麻烦的是循环外键（A→B→A），模型会加载成功但无法生成有效 DDL。
- 导入前先在原库跑依赖查询，例如 MySQL：
SELECT TABLE_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND REFERENCED_TABLE_NAME IS NOT NULL;
- 发现循环依赖，必须拆成两批导入：先导入无依赖的表，保存模型；再打开新模型，单独逆向有依赖的表，最后用
添加关联的对象手动连线 - 同名表（如不同 schema 下都有
users）导入后会冲突，Navicat 默认用schema_name.table_name命名，但画布上只显示users，容易混淆——建议导入后立即右键重命名为auth_users、crm_users
物理模型不是画完连线就结束，它本质是数据库的“可执行蓝图”。真正容易被忽略的点在于：模型里每个外键、索引、字段注释，最终都会变成 SQL 里的 ADD CONSTRAINT 或 COMMENT ON COLUMN——少设一个，上线后就得补迁移脚本。
