正向生成数据库需手动核对模型与连接的数据库类型、版本、字符集、权限等匹配性，同步到数据库直接执行DDL不可逆，同步到文件仅生成SQL脚本；外键、索引、CHECK约束按模型严格生成，字段注释可能因字符集不支持被截断。
正向生成数据库不是“一键建库”，而是把物理模型里的完整结构翻译成目标库能执行的 ddl 并执行——跳过已存在表、不自动加事务、外键/索引可能静默失败，这些都得你亲手核对。
同步前必须确认模型和连接完全匹配
Navicat 不会帮你“猜”兼容性。模型里选的是 MySQL 8.0，但连接连的是 MySQL 5.7 实例？那 JSON 字段、隐藏索引、DESC 在 ORDER BY 中的行为都会出错或被忽略。字符集也一样：utf8mb4_unicode_ci 模型 + latin1_swedish_ci 连接 = 建表时可能退化为 utf8mb4_general_ci，后续 emoji 或中文排序异常。
- 在模型属性里右键 →「编辑模型」→ 核对「目标数据库类型与版本」
- 在 Navicat 主界面右键目标连接 →「编辑连接」→ 查看「字符集」和「排序规则」是否与模型一致
- 用该连接用户手动执行
SHOW GRANTS，确认有CREATE、ALTER、INDEX、REFERENCES权限（缺REFERENCES会导致外键报ERROR 1215）
“同步到数据库”和“同步到文件”行为完全不同
点错入口，结果天差地别：
-
同步到数据库：直连执行 DDL，删表、改字段类型、删索引都会立即生效，不可逆 -
同步到文件：只生成纯 SQL 脚本（含CREATE TABLE、ALTER TABLE ADD CONSTRAINT等），不碰真实库——这才是上线前该走的路
注意：同步到文件 生成的 SQL 默认不包 BEGIN; ... COMMIT;。脚本里有 5 张表变更，第 3 步失败，前 2 步已执行且不会回滚。要么自己加事务包装，要么拆成单表原子脚本再跑。
为什么外键、索引、CHECK 约束经常“没过去”
不是 Navicat 漏了，是它严格按模型定义来，不脑补、不推测：
- 模型里外键没设
ON DELETE CASCADE，生成的 SQL 就不会有这句，数据库里自然也没 - 索引名在模型里是空的？Navicat 会自动生成类似
idx_12345的名字，但如果你依赖特定索引名做查询优化，就得提前填好 -
CHECK约束在 MySQL 8.0.16+ 才默认启用；若目标库是 5.7 或 8.0.15-，约束会被忽略且无提示 - 字段类型映射有边界：模型选
TINYINT，对 PostgreSQL 模型压根不提供这个选项——因为 PG 没这类型，选了也同步不了
实际操作中容易忽略的关键点
正向工程真正卡住人的，往往不是语法错误，而是隐性状态：
- 目标库已存在同名表时，默认行为是「跳过」，不是报错也不是覆盖。你以为同步失败，其实是 Navicat 在保护数据——得手动勾选「删除不存在的对象」或「重新创建对象」才改变行为
- 模型里字段设了注释，但目标库字符集不支持 emoji（比如只用了
utf8而非utf8mb4），注释内容会被截断或转成问号，且 Navicat 不报错 - 视图、存储过程能否同步，取决于模型类型（必须是物理模型）和 Navicat 版本（旧版 Premium 可能不支持 PG 的函数同步）
最麻烦的从来不是“怎么点”，而是“点完之后哪些东西没按你想的那样落地”。盯住日志窗口里的每一条 SQL 和返回码，比盯着进度条重要得多。
