Navicat 16 默认不生成 DROP 语句是因启用「安全模式」,默认未勾选“Drop objects not exist in source”,防止误删手动添加的对象,属设计策略而非 bug。
为什么 Navicat 16 默认不生成 DROP 语句
navicat 16 的结构同步默认启用「安全模式」:它假设目标库可能含手动添加的表、字段或索引(比如 dba 临时加的调试列),所以不会主动删任何东西。这背后控制开关就是 drop objects not exist in source,默认未勾选——不是 bug,是设计策略。
取消勾选后仍出现 DROP 的真实原因
即使你确认该选项已取消,仍看到 DROP COLUMN 或 DROP TABLE,大概率是以下情况之一:
- 你在「源对象」树形列表里手动取消了某张表的勾选(右键 → Uncheck),但 Navicat 把这理解为“源中不存在”,于是对目标库执行删除操作
- 同步前你改过源库连接的「默认 Schema」,导致 Navicat 实际比对的是空 schema,误判目标库所有对象都“多余”
-
Compare foreign keys被勾选,而源库外键名和目标库不一致(比如fk_order_user_idvsorder_user_id_fk),Navicat 会先删旧外键再建新外键
真正禁用所有 DROP 类操作的配置组合
单靠一个选项不够,必须同时满足:
- 在「选项」→「常规」中,取消勾选
Drop objects not exist in source - 在「选项」→「高级」中,取消勾选
Compare auto-increment value(否则可能触发ALTER TABLE ... AUTO_INCREMENT = N,间接导致主键重置风险) - 进入「结构比对」界面,在左侧
Source Objects树里,确保所有表、视图、函数节点都处于勾选状态(哪怕你暂时不打算同步它们,也要保持勾选;想跳过请用部署脚本阶段人工注释) - 若目标库有同名但结构不同的表,不要依赖同步覆盖——先手动导出原表 DDL 备份,再决定是否删表重建
预览 SQL 时怎么快速识别残留 DROP
点开「预览 SQL」页签后,别从头扫,直接搜索关键词:
- 搜
DROP TABLE:出现即违规,立刻回退检查源对象勾选状态 - 搜
DROP COLUMN:常见于字段重命名(Navicat 把RENAME COLUMN拆成DROP + ADD),此时应勾选「忽略列顺序」并确认源库用了 MySQL 8.0+ 的重命名语法 - 搜
FOREIGN KEY:若看到成对的DROP FOREIGN KEY和ADD CONSTRAINT,说明Compare foreign keys生效了,且外键名不一致
最易被忽略的是:当你用不同用户连接源/目标库,PostgreSQL 下因 search_path 差异,Navicat 可能根本没加载到某些 schema 的对象,却在目标库发现它们,从而判定为“需删除”。这时候得分别配两个连接,每个指定固定 schema。











