navicat 不支持模型分支合并，.ncm 文件无版本/分支概念，仅能通过导出 sql 后用外部工具 diff 比对差异，并需手动同步易遗漏的 char/varchar、索引前缀、默认值表达式等细节。
直接说结论：Navicat 本身不支持「模型分支合并」，所谓“合并两个独立演进的数据库设计模型”，本质是人工比对差异 + 手动同步变更，不能依赖自动合并功能。
Navicat 模型文件（.ncm）没有版本/分支概念
你保存的每个 .ncm 文件都是一个完整快照，Navicat 不记录修改历史、不标记变更点、不提供 diff 视图。它不像 Git 那样能告诉你“这张表在 v1 模型里有 status 字段，在 v2 模型里被重命名为 state”。你打开两个模型文件，只能并排看——靠人眼找区别。
- 模型设计不走「结构同步」流程：工具→结构同步 是针对**已存在的数据库实例**，不是针对 .ncm 文件
- 右键模型 →「同步到数据库」只是单向导出当前模型为 DDL，不会读取目标库反向更新模型
- 不存在「合并模型 A 和模型 B 到新模型 C」的菜单项或向导
真正可行的模型比对路径：导出 SQL → 用外部工具 diff
想看出两个模型之间的结构差异，唯一可靠的做法是把它们都转成可比对的文本格式：
- 分别打开两个
.ncm模型 → 右键根节点 →「生成 SQL 脚本」→ 保存为v1_schema.sql和v2_schema.sql - 确保导出时勾选「包含 DROP TABLE IF EXISTS」和「包含外键定义」，否则缺失约束会导致 diff 失真
- 用命令行或 IDE 工具比对：
diff v1_schema.sql v2_schema.sql，或粘贴到 VS Code / Beyond Compare 中查看高亮差异 - 注意过滤掉自动生成内容：如时间戳注释、Navicat 特有元数据（
-- Created by Navicat...）、空行顺序——这些不是模型语义差异
手动同步变更时最容易漏掉的三类结构
即使你看出了字段增删，也常会忽略以下 MySQL 层面实际生效但模型里不显眼的细节：
-
CHARvsVARCHAR长度隐式截断：模型里都写name VARCHAR(50)，但源模型导出的 SQL 实际可能是name CHAR(50)，建表时行为完全不同 - 索引顺序与覆盖性：模型里画了复合索引
(a,b,c)，但没标是否唯一、是否前缀索引（a(10),b,c），导出 SQL 若漏掉前缀长度，线上执行会失败 - 默认值表达式：模型里填
CURRENT_TIMESTAMP，但导出 SQL 可能写成NOW()或漏掉ON UPDATE CURRENT_TIMESTAMP，这在严格模式下直接报错
模型是草图，SQL 是合同。再漂亮的模型连线，不落地成带字符集、排序规则、SQL_MODE 兼容性的 DDL，就只是纸上谈兵。每次同步前，务必用 mysql --defaults-file=prod.cnf -e "SHOW CREATE TABLE ..." 对照验证真实环境行为。
