navicat“结构同步”是以生成变更脚本为目标的同步向导，非单纯表结构比对工具；源库（左侧，基准）与目标库（右侧，待修改）方向选错会导致误删字段，须通过顶部状态栏确认“将对test_old应用更改”，并手动逐条核对ddl差异、忽略无关项。
navicat 的“结构同步”不是表结构比对工具，而是以“生成变更脚本”为目标的同步向导；直接点“对比”看到的差异，取决于你选错源和目标——方向一反，脚本就删库字段。
选源库和目标库时，必须看清楚哪边是“要被改的”
Navicat 界面只写“数据库1”“数据库2”，不标“源/目标”。但逻辑上：左侧是 源库（你要参考的基准，比如新环境的 test_new），右侧是 目标库（你准备动手改的那个，比如旧环境的 test_old）。如果拖反了，它会生成“删掉 test_new 字段”的脚本，而不是给 test_old 加字段。
- 比对完成后，紧盯顶部状态栏文字：必须显示“将对
test_old应用以下更改”才说明方向正确 - 若发现错了，别点“部署”或“运行”，直接关掉重开，重新拖拽顺序
- 右键数据库连接 → “编辑连接” → 在连接名里加注释，比如“【目标-待升级】”“【源-基准】”，避免手滑
大量黄色“修改”差异，大概率只是 COLLATE 或字符集不同
两个表字段名、类型、长度完全一样，Navicat 却标为“修改”，点开 DDL 比较标签一看，只有 COLLATE utf8mb4_unicode_ci 和 COLLATE utf8mb4_0900_as_cs 的区别——这种差异不影响查询逻辑，但会触发 ALTER TABLE ... CONVERT TO CHARACTER SET，可能锁表或引发隐式转换。
- 每条差异项都要点开，到底部“DDL 比较”标签里逐行核对，重点盯
CHARACTER SET、COLLATE、COMMENT、ENGINE - 确认无关后，右键该行 → “忽略此项”；Navicat 不支持批量忽略，必须一条条手动点
- 别信“忽略默认值”或“忽略列顺序”这类全局选项——它们对 COLLATE 无效，只影响
DEFAULT '2023-01-01'这类引号格式
索引差异藏得深，不点开 DDL 比较根本看不出问题
Navicat 把索引当成整体对象比：名字不同就标“删除+新建”，字段顺序变了、前缀长度变了（如 col_b(10) vs col_b）、ASC/DESC 排序方向变了，全都不会单独列出，只在 DDL 比较面板里暴露。
- 右键任意索引相关差异项 → “在 DDL 比较中查看”，才能确认是不是字段顺序调换了
- MySQL 8.0+ 的函数索引（如
KEY ((UPPER(email)))）必须两边写法一字不差，否则直接报不一致，且不高亮函数体差异 - 跨库比对时，若两张表
COLLATE不同，Navicat 会判定索引“需重建”——这不是 bug，是真实风险：排序规则变，索引可能无法用于ORDER BY或WHERE
视图/存储过程这些关键对象，默认根本不比
结构同步默认只比表和字段。如果你只盯着“表结构差异”，上线后发现某个报表查不到数据，大概率是视图定义里少了一列——而 Navicat 根本没提醒你。
- 在“对象选择”页，务必手动勾选
Views、Stored Procedures、Triggers；Functions和Events可酌情取消（它们的差异常由空格、注释引发误报） - 视图定义变更往往比表结构变更更致命，但 Navicat 不会自动推断“这个视图依赖这张表”，必须人工覆盖比对范围
- 比对前确认目标库用户有
SHOW VIEW权限，否则视图那一栏永远空白
最麻烦的不是看不懂差异，而是你以为看懂了——比如把 MODIFY COLUMN 当成安全调整，结果它悄悄重建了 ENUM 字段；或者把“忽略 COLLATE”当成无害操作，却忘了线上排序行为已变。所有 DDL 预览都得逐行过眼，不能信顶部那句“共发现 12 处差异”。
