同步模型到数据库前必须保存模型并确保结构合法，包括表有主键、字段类型兼容目标库、显式指定字符集；需区分双向同步方向，人工核对DDL脚本，增量变更应通过版本比对+手动ALTER实现。
同步模型到数据库前必须确认模型已保存且结构合法
navicat 16 的「同步模型到数据库」不是一键推演，而是基于已存在的 .nmmp 模型文件执行 ddl 生成与执行。如果模型未保存、或存在未命名表、无主键实体、字段类型不被目标数据库支持（比如 mysql 中用了 json 类型但目标库是旧版 5.7），同步会直接失败或跳过部分对象。
实操建议：
- 右键模型画布空白处 →
保存模型，确保路径下有实际文件（如order_model.nmmp）； - 检查所有表是否设置了主键：右键表 →
编辑表→ 确认至少一个字段勾选了PK； - 避免使用目标库不支持的类型：MySQL 5.7 不支持
JSON，PostgreSQL 不识别TINYINT，需手动改用SMALLINT或BOOLEAN； - 字符集要显式指定：在模型表属性里设置
Collation为utf8mb4_unicode_ci，否则同步后可能默认latin1导致中文乱码。
“同步模型到数据库”和“同步数据库到模型”方向不能反
这两个功能入口都在模型编辑界面右键菜单，但行为完全相反：同步模型到数据库 是把模型里的表/字段/关系变成真实 SQL 执行；同步数据库到模型 是反向读取现有库结构生成新模型。选错会导致生产库被删表、或本地模型被覆盖重写。
常见错误现象：
- 点了
同步数据库到模型却想更新线上库 → 实际只是刷新了本地模型，没动数据库； - 目标库已有同名表，但没勾选
删除不存在的对象→ 新增字段不会生效，因为 Navicat 默认只建缺失表，不 ALTER 已存表； - 勾选了
删除不存在的对象但目标库有业务数据 → 表被 DROP，不可逆。
DDL 预览和部署脚本必须人工核对
点击 同步模型到数据库 后，Navicat 会弹出「部署脚本」窗口，列出所有将执行的 CREATE TABLE、ALTER TABLE 语句。这不是示意，而是即将运行的真实 SQL —— 它不会自动加事务包装，也不会跳过失败语句（除非勾选 遇到错误时继续）。
关键操作点：
- 切换到
DDL 比较标签页，确认每条语句是否符合预期（比如ADD COLUMN created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP是否带了NOT NULL，会不会因存量数据为空而报错）； - 点击
部署选项→ 勾选遇到错误时继续仅适用于批量建表场景，不适用于含数据迁移的复杂变更； - 务必点击
在查询编辑器打开脚本，复制 SQL 到新查询窗口手动执行前先加BEGIN; ... ROLLBACK;测试； - 若模型含外键，注意目标库引擎是否支持（MyISAM 不支持 FK，必须用 InnoDB）。
增量变更只能靠模型版本管理 + 手动比对
Navicat 16 没有内置的「差异增量同步」机制。比如你只改了一个字段长度，它不会智能生成 MODIFY COLUMN，而是重新生成整张表的 CREATE TABLE 语句（含 DROP TABLE IF EXISTS）。这意味着——
实操中真正安全的做法是：
- 每次模型变更后，另存为新版本（如
order_v2.nmmp），用 Navicat 的比较模型功能找出差异； - 根据差异手动写
ALTER TABLE脚本，而不是依赖「同步模型到数据库」全自动执行； - 对线上库操作前，导出当前结构（右键库 →
转储 SQL 文件），再对比模型生成的 DDL，确认无破坏性操作； - 涉及索引、触发器、存储过程等高级对象时，Navicat 模型同步默认不处理，必须单独导出/导入。
最易被忽略的是：模型里设置的「自动递增」、「默认值」、「注释」这些元信息，在同步时可能被忽略或转换异常，尤其是跨数据库类型（如从 MySQL 模型同步到 PostgreSQL）时，COMMENT ON COLUMN 和 COMMENT 语法完全不同，得手动补全。
