新建物理模型必须手动选“物理”类型、指定具体数据库（如MySQL）及匹配版本（如8.0），否则导出SQL可能缺失DEFAULT CURRENT_TIMESTAMP或错误索引；字段需设长度、空值、默认值格式，外键要求类型/字符集/索引三者严格一致。
必须先选对模型类型，否则后续所有主键、外键、字段约束都设不了——新建时“模型类型”下拉框默认是物理，但数据库和版本必须手动指定，不能留空。
新建物理模型时最关键的三步配置
Navicat 不会帮你猜目标库，物理模型一旦建错，改起来比重做还麻烦。重点不是“能不能画”，而是“生成的 SQL 能不能在目标库跑通”：
- 点
文件 → 新建模型后，在弹窗中确认模型类型是“物理”（默认常为该选项，但需肉眼核对） -
数据库下拉框必须选具体类型，比如MySQL、PostgreSQL或DM8（达梦），不能选“通用”或留空 -
版本要匹配实际部署环境，例如 MySQL 5.7 和 MySQL 8.0 对JSON字段、隐式主键、DEFAULT CURRENT_TIMESTAMP的支持差异极大
漏选版本最典型的问题：导出 SQL 时 DATETIME 字段没带 DEFAULT CURRENT_TIMESTAMP，或 TEXT 字段被错误加了索引（MySQL 8.0+ 不允许）。
添加表后必须立即检查的字段属性项
右键表 → 编辑表 打开的默认视图只显示字段名和类型，真正影响建表成败的细节全藏在「属性」面板里：
-
长度/精度：比如VARCHAR必须填数字，留空会变成VARCHAR(255)；DECIMAL必须同时设精度和小数位数 -
允许为空：勾与不勾直接决定是否生成NOT NULL约束，逻辑模型转过来的常默认为空，但业务字段如user_id实际不可为空 -
默认值：字符串要用单引号包裹，如'pending'；函数类默认值如CURRENT_TIMESTAMP必须去掉引号，否则导出为字面量 -
AUTO_INCREMENT或SERIAL：主键字段不手动勾选，导出 SQL 就不会有自增逻辑，同步到库时也不会建PRIMARY KEY
常见翻车点：id 字段类型设成 BIGINT 却忘了勾 AUTO_INCREMENT，结果同步时报 “Key column 'id' doesn't exist in table”。
建立外键关系前务必核对的三项一致性
Navicat 允许拖线建关联，但不会校验底层字段是否真能连上。多数同步失败都卡在这一步：
- 字段类型完全一致：比如主表
order_id是BIGINT UNSIGNED，从表外键也必须是BIGINT UNSIGNED，差一个UNSIGNED在 MySQL 8.0+ 直接拒绝建外键 - 字符集与排序规则一致：两个
VARCHAR字段即使长度相同，若一个是utf8mb4_0900_as_cs、另一个是utf8mb4_general_ci，外键创建失败 - 被引用字段必须有索引：主表的
status_code若没建索引，哪怕你拖线成功，导出 SQL 时也不会生成FOREIGN KEY语句
建议做法：先在主表字段上右键 → 设置为主键 或 新建索引，再拖线。别依赖 Navicat 自动补索引。
导出或同步前最容易忽略的两处“静默丢失”
你以为导出了完整结构，其实关键信息早被过滤掉了：
-
Comment（字段/表注释）：逻辑模型里的Description不会自动落到物理模型的Comment属性里，必须手工复制粘贴，否则CREATE TABLE语句里没有COMMENT子句 -
存储引擎和字符集：物理模型默认用数据库全局设置，但如果你的项目要求所有表强制ENGINE=InnoDB DEFAULT CHARSET=utf8mb4，就得在每个表属性里手动填进Engine和Collation字段
复杂点在于：这些字段在模型画布上完全不可见，全靠点击表 → 属性 面板逐个翻找。赶时间时最容易漏。
