Navicat 16的模型同步不是数据库重构工具，而是双向比对+脚本生成器；必须先建模再比对差异，严禁直接拖拽改生产库，且需人工核查外键、触发器、数据迁移等高危项。
建模器与数据库重构不是一回事，别直接拖拽改生产库
navicat 16 的「模型同步」功能常被误当作“重构工具”，但它本质是双向比对 + 脚本生成器，不是无脑覆盖。你用它删字段、改主键、重命名表时，它不会自动处理外键依赖、触发器或应用层 sql 引用——这些全得你人工确认。一旦跳过预览直接执行，alter table 报错或数据丢失就是分分钟的事。
真正提效的关键在“先建模、再比对、最后只同步差异”
重构前必须把目标结构画进模型（Model），而不是直接连生产库改。这样做的好处是：能提前发现逻辑矛盾，比如循环外键、缺失索引、字段类型不匹配；还能导出 DDL 脚本给 DBA 或 DevOps 审核。操作流程要严格按顺序来：
- 新建空白模型，手动绘制或从现有库反向工程（
Reverse Engineering）导入当前结构 - 在模型里修改：加表、调字段顺序、设
NOT NULL、补CHECK约束——所有改动都在模型层完成 - 右键模型 →
Sync to Database→ 选目标连接 → 勾选Compare only先看差异报告 - 重点检查「将被删除的索引」「将被修改的默认值」「可能引发锁表的列类型变更」这几类高危项
模型同步默认不处理数据迁移，大字段变更容易卡死
比如你要把 VARCHAR(255) 扩到 VARCHAR(2000)，模型同步生成的 ALTER TABLE ... MODIFY COLUMN 在 MySQL 5.7+ 会隐式重建表，如果这张表有千万级数据，同步过程可能持续数小时，且期间写入阻塞。这不是 Navicat 的 bug，而是底层数据库行为。应对方式很实际：
- 对大表变更，务必取消勾选
Sync data（它默认关着，但有人会手抖打开） - 涉及
TEXT、BLOB或长度 > 500 的VARCHAR列，同步前手动拆成两步：ADD COLUMN+UPDATE+DROP COLUMN - 用
Query Analyzer查看同步生成的脚本，把长事务拆成带WHERE条件的分批更新
协同重构时，模型文件比 SQL 脚本更可靠
团队共用一个模型文件（.nmf），比传 .sql 脚本靠谱得多。因为 .nmf 里存的是结构元数据+关系图谱，不会因手工编辑漏掉 FOREIGN KEY 名字或 ON DELETE CASCADE 行为。但要注意两个坑：
-
.nmf文件不能直接 merge，Git 冲突时是二进制乱码，必须靠 Navicat 自带的Compare Models功能人工合并 - 不同 Navicat 版本保存的
.nmf格式不完全兼容，16.0 和 16.2 之间偶尔会提示“模型版本不支持”，建议团队统一小版本号
Sync to Database 前，盯着差异窗口里那几行红色文字看三秒——那里藏着你明天凌晨三点被叫醒的原因。
