正向工程可能删表删字段，取决于是否勾选“Drop objects not exist in source”；逆向工程绝对安全，不执行任何DDL；同步前必须关闭三个高危选项并预览SQL。
模型同步本身不删数据，但正向工程可能触发删字段/删表
navicat 的「模型同步」（.nmodel 文件 ↔ 数据库）默认只改结构，不碰数据。但如果你选的是正向工程（模型 → 数据库），且模型里删了字段、删了表，而同步选项又没关掉 drop objects not exist in source，那生成的 sql 就真会执行 drop column 或 drop table——这时候数据就没了。
关键不是“模型同步会不会删”，而是你选的方向 + 勾选的选项共同决定行为：
- 逆向工程（数据库 → 模型）：只读取结构，绝对不发任何 DDL，安全
- 正向工程（模型 → 数据库）：按模型差异生成 DDL，
DROP类操作是否执行，取决于同步对话框里的开关 -
Compare auto-increment value这个默认勾选，但实际不该开——它会把自增起始值也当成结构同步，导致目标表主键重置，后续插入可能冲突
同步前必须关掉的三个高危选项
点开「结构同步」→「选项」→「高级」，以下三项不手动关掉，等于把生产库交给随机函数：
-
Drop objects not exist in source：勾选 = 允许删表、删字段、删索引。上线前若源模型还没冻结，误删几乎必然发生 -
Compare comments：MySQL/PG 支持注释，但旧版 Oracle 不支持COMMENT ON COLUMN，一同步就报错中断，还可能卡在半截 DDL 里 -
Compare collation：字符集校对规则不同会强制加ALTER TABLE ... CONVERT TO，某些组合（如utf8mb4_0900_as_cs→utf8mb4_general_ci）会因排序规则不兼容直接失败
预览SQL是唯一能救命的步骤
Navicat 同步永远先弹窗预览，不是摆设。真正出事的团队，90% 都跳过了这一步。
- 逐行扫
ALTER TABLE ... DROP COLUMN—— 如果你没打算删这个字段，立刻关掉同步，回模型里检查是不是误删了 - 留意
MODIFY COLUMN是否带NOT NULL约束：目标表该字段若有空值，这条语句会直接失败 - 看到
CREATE TABLE ... SELECT或临时表重命名操作，说明 Navicat 在模拟原子变更，但某些 MySQL 版本下仍可能锁表数秒 - 如果预览里出现
TRUNCATE或DELETE FROM，说明你点错了功能——那是「数据同步」，不是「模型同步」
模型文件怎么管才不会同步翻车
.nmodel 是 XML，可 diff、可 Git 版本控制，但很多人把它当二进制文件扔进仓库，结果 merge 冲突后直接覆盖，模型和库就彻底失联。
- 导出模型必须选
Export as XML，不能用二进制 .nmodel 直接提交 - 每次模型变更，由指定 Owner 提 PR，审查点包括：删了哪些字段、加了哪些索引、是否涉及外键变更
- 同步前，用 Navicat 打开本地 .nmodel，右键「逆向工程」到开发库，确认模型和当前库结构一致——避免“你以为删了字段，其实只是没同步到模型”
- 禁止多人同时编辑同一 .nmodel；Git 冲突时，宁可手写 XML 修复，也不要盲目接受某一方版本
模型同步最危险的不是功能本身，而是人误以为它是“安全的自动化”。只要漏看一行 DROP，或者忘了关掉那个默认勾选的 Drop objects not exist in source，就足够让一个上线窗口变成事故复盘会。
