navicat模型对比（model comparison）仅比对.nmmp文件差异，不生成可执行ddl；生成同步sql的唯一路径是tools→structure synchronization，且源/目标必须为已连接的真实数据库，并勾选“generate sql file only”避免误执行。
模型对比工具不直接生成结构同步SQL
Navicat 17 的「模型工作区」里的模型对比（Model Comparison）功能，仅用于比对两个数据库模型（.nmmp 文件）之间的差异，它不会生成可执行的 DDL SQL，也不会触发结构同步流程。真正能输出变更 SQL 的路径是「结构同步」（Structure Synchronization），而它和模型对比是两套独立机制。
常见误操作是：在模型工作区右键两个模型 → 选 Compare，看到差异后以为点“生成脚本”就能导出 ALTER 语句——实际该界面只有「Merge」（合并到当前模型）按钮，没有导出 SQL 选项。
- 模型对比结果只显示“表新增/删除/字段增删改”，不生成任何 SQL 文本
- 它不连接真实数据库，因此无法校验引擎兼容性、权限或外键依赖
- 合并操作仅修改本地 .nmmp 文件，不影响任何数据库实例
- 若你最终目标是生成同步 SQL，必须退出模型工作区，回到主界面走结构同步流程
结构同步才是生成可执行DDL的唯一入口
要拿到真实的、带 ALTER TABLE 的变更 SQL，必须使用 Tools → Structure Synchronization，且确保源和目标都是已连接的**真实数据库**（不是模型文件）。
关键步骤和易错点：
- 必须先建立两个可用连接（如
dev_db和prod_db），不能用模型文件或脱机备份作为源/目标 - 进入向导后第一步选「Synchronize two databases」，不是「Synchronize two models」——后者根本不存在
- 点击「Next」后，在「Options」里务必勾选「Generate SQL file only」，否则默认会直接执行（高危！）
- 预览窗口中每条变更左侧有小图标：
ADD COLUMN、DROP INDEX等，点击可展开对应 SQL；但注意：这里显示的是 Navicat 解析后的标准格式，可能和原始建表语句写法不同（比如自动补全USING BTREE）
为什么预览SQL和最终执行可能不一致
结构同步预览里的 SQL 是 Navicat 根据差异自动拼装的，但它不模拟执行环境，因此存在几类典型偏差：
- 字段类型变更如
VARCHAR(50) → VARCHAR(255)会生成MODIFY COLUMN，但如果该列上有全文索引，MySQL 8.0+ 实际拒绝执行该语句 - 删主键时若被外键引用，预览仍显示
DROP PRIMARY KEY，但执行时报错Cannot drop index 'PRIMARY': needed in a foreign key constraint - 目标库字符集为
utf8mb4_0900_as_cs而源库是utf8mb4_unicode_ci，预览可能不体现 COLLATE 变更，但实际会影响索引匹配行为 - Navicat 默认用
MODIFY COLUMN，除非你手动改了字段名，否则不会用CHANGE COLUMN——这对某些迁移工具（如 Flyway）识别变更粒度有影响
真正需要关注的细节不在预览界面里
结构同步向导的预览界面只告诉你“要做什么”，但不解释“为什么这么做”或“有没有隐含风险”。最容易被忽略的是：
点开任意一条差异项 → 右键 → 「View DDL Comparison」，才能看到源库和目标库各自的完整 SHOW CREATE TABLE 输出，并高亮行级差异。这里才能确认是不是字段顺序变了、前缀长度（如 name(10)）是否被当成实质变更、或者 ASC/DESC 排序方向是否被错误标记（尤其在 MySQL 5.7 上该语法无效却仍被比对）。
别跳过这一步——很多线上事故就源于把“看起来一样”的索引当成无差异，结果因为字段顺序或 COLLATE 不同，导致查询性能断崖式下跌。
