正向工程同步的是物理模型中定义的完整对象结构与约束，包括表结构、字段类型及长度、主键/外键、索引、CHECK约束、默认值、注释、视图和存储过程等，而非仅建表。
正向工程到底在同步什么？别误以为只是“建表”
正向工程不是一键生成数据库，而是把物理模型中定义的**完整对象结构与约束**，按目标数据库语法翻译并应用到真实环境。它同步的包括：表结构、字段类型及长度（如 varchar(255)）、主键/外键定义、索引（含唯一索引）、check 约束、默认值、注释，甚至视图和存储过程（取决于模型内容和 navicat 版本支持）。
- 如果你模型里某个外键没设级联动作（ON DELETE CASCADE），正向工程后数据库里也不会有——它不会“脑补”逻辑
- 字段类型会自动映射：模型中选
INT，对 MySQL 就是INT，对 PostgreSQL 就转成INTEGER；但像TINYINT这种 MySQL 特有类型，在 PostgreSQL 模型里压根不会出现选项 - 若目标数据库已存在同名表，默认行为是「跳过」而非覆盖——这点极易被忽略，导致你以为“同步失败”，其实是 Navicat 在保护数据
同步前必须检查的三个关键配置项
正向工程失败或结果异常，80% 出在模型与连接配置不匹配。重点核对以下三项：
-
模型的目标数据库类型与版本：新建模型时选的是MySQL 8.0，但你连的是MySQL 5.7实例？那JSON字段、隐藏索引等特性会直接报错或降级处理 -
数据库连接的字符集与排序规则：模型里字段设了utf8mb4_unicode_ci，但连接用的是latin1_swedish_ci？建表时可能静默退化为utf8mb4_general_ci，后续中文排序或 emoji 存储出问题 -
当前连接用户权限：需要CREATE、ALTER、INDEX、REFERENCES权限；缺REFERENCES会导致外键创建失败，错误提示常是模糊的ERROR 1215
“同步模型到数据库”和“同步模型到文件”的本质区别
这两个入口看似相似，底层行为完全不同，选错会耽误调试节奏：
-
同步模型到数据库：直连执行 DDL，立即生效。适合开发环境快速验证结构，但不可逆——删表、改字段类型等操作会直接作用于库 -
同步模型到文件：只生成标准 SQL 脚本（含CREATE TABLE、ALTER TABLE ADD CONSTRAINT等），不触碰数据库。这才是上线前必走流程：你可以用git diff对比脚本变更，加--dry-run在测试库跑一遍，甚至人工删掉危险语句（比如DROP COLUMN） - 注意：Navicat 生成的 SQL 默认不含事务包装。如果脚本里有多个表变更，而中间某步失败，前面已执行的 DDL 不会自动回滚——得自己包一层
BEGIN; ... ; COMMIT;或拆成原子脚本
外键和索引为什么有时“没同步过去”？
这不是 Bug，而是 Navicat 的显式设计逻辑：它只同步模型中**明确启用**的对象属性。常见漏点：
- 字段设了外键关系线，但该字段在模型里没勾选
FK标识（右键字段 → 属性 → 勾选Foreign Key）→ 同步时只建字段，不建约束 - 模型里画了关系线，但没在关系属性中指定“参照完整性”（如 ON UPDATE CASCADE）→ 同步后只有基础外键，无级联行为
- 索引未在字段属性中手动添加：即使你双击表看到“索引”页签为空，也不代表没索引；必须进每个字段属性，勾选
Index并命名，或单独用工具栏新建索引工具绘制
最稳妥的做法是：同步前，在模型中右键任意空白处 → 选择 验证模型，它会高亮标出所有缺失主键、未启用外键、重复索引等问题——这个弹窗别跳过。
