结构同步前须确认源目标方向：左侧为源、右侧为目标，拖错将导致ALTER脚本反向执行；所有差异须点开DDL比较面板逐条核对CHARACTER SET、COLLATE等元数据及索引细节，并手动忽略无关项；视图、存储过程等高级对象需手动勾选比对。
结构同步前必须确认源和目标方向
navicat 17 的结构同步默认以左侧为「源」、右侧为「目标」，但界面只显示“数据库1”“数据库2”，不标注源/目标。一旦拖错顺序，生成的 alter table 脚本会反向执行——比如你想把 test_old 升级成 test_new 的结构，结果脚本却去删 test_new 的字段。
实操建议：
- 打开结构同步窗口后，先手动把「当前要更新的那个库」拖到左侧（即源），「作为基准的那个库」拖到右侧（即目标）
- 点击
对比后，看顶部状态栏是否显示“将对[左侧库名]应用以下更改”——这是唯一能快速验证方向正确的提示 - 如果发现方向错了，别点
部署或运行，直接关闭重开，重新拖拽顺序
比对结果里标黄的“修改”不等于业务变更
常见现象：两个表字段名、类型、长度完全一致，Navicat 却标为黄色“修改”，点开DDL 比较标签才发现只是 COLLATE utf8mb4_0900_as_cs 和 COLLATE utf8mb4_unicode_ci 不同。这类元数据差异不影响查询逻辑，但会触发 ALTER TABLE ... CONVERT TO CHARACTER SET，可能锁表或引发隐式转换。
实操建议：
- 每条差异项都要点开底部的
DDL 比较标签，重点盯CHARACTER SET、COLLATE、COMMENT、ENGINE这几处 - 确认是无关差异后，右键该条目 → 选择
忽略此项；Navicat 不支持批量忽略或按规则过滤，必须逐条手动点 - 别跳过这步——很多线上事故就源于没看 DDL 比较，直接点了部署
索引差异必须进 DDL 比较面板肉眼核对
Navicat 能识别索引增删，但默认不展开字段顺序、唯一性、前缀长度、排序方向（ASC/DESC）等细节。比如 KEY idx_a (col_b(10), col_a) 和 KEY idx_b (col_a, col_b(10)) 会被标为“修改”，但具体改了什么，得点开DDL 比较才能看清。
实操建议：
- 不要只扫“操作类型”列；右键每条索引相关差异 → 选
在 DDL 比较中查看 -
col_b(10)和col_b在 Navicat 看来就是不同字段，即使业务上没区别；它也不会提示“前缀长度可忽略” - 跨库比对时，若两边
COLLATE不同（如utf8mb4_0900_as_csvsutf8mb4_unicode_ci），Navicat 会判定索引需重建——这不是误报，而是真实风险：排序规则变，索引可能无法用于ORDER BY或WHERE
视图/存储过程/触发器默认不参与比对
结构同步默认只比表和字段，但升级中真正影响功能的往往是视图定义变更、触发器逻辑调整、存储过程参数增减。如果漏选这些对象，上线后可能突然报错，追查才发现是视图少了一个 SELECT 列。
实操建议：
- 在结构同步设置页，务必手动勾选
比对视图、比对存储过程、比对触发器、比对函数、比对事件等高级对象 - 尤其注意：MySQL 8.0 的 invisible index 属性在 5.7 不支持，Navicat 会把“可见性变化”当作索引定义变更；若源库是 5.7、目标库是 8.0，得提前人工检查这类兼容性
- 部署前再扫一遍比对结果列表，确认没有遗漏关键对象——DDL 脚本里没出现的，往往就是没勾选的
DDL 比较面板里的细节。Navicat 只负责比“语法层面是否一致”，不推理语义等价性，也不做版本兼容性兜底。你看到的每一条“修改”，都得亲手点开确认到底改了什么。
