源库和目标库选反会导致DDL方向错误：Navicat 17默认左侧为源（待更新库）、右侧为目标（对齐基准库），界面仅标“数据库1/2”无明确提示；选反后会生成删除基准库字段而非补全待更新库的脚本，部署即破坏新库；必须通过顶部状态栏“将对[左侧库名]应用以下更改”验证方向，错误则重开并重新拖拽顺序。
源库和目标库选反了，生成的 DDL 就是错的
navicat 17 的结构同步默认以左侧为「源」、右侧为「目标」，但界面只写“数据库1”“数据库2”，不标“源/目标”。一旦拖错顺序，比如把待升级的 test_old 放右边、基准库 test_new 放左边，它就会生成「删掉 test_new 字段」的脚本，而不是补全 test_old ——部署后直接破坏新库。
实操建议：
- 先确认：左侧必须是你「当前要更新」的库（如旧环境），右侧是「希望对齐」的基准库（如新环境）
- 比对完成后，紧盯顶部状态栏是否显示“将对
[左侧库名]应用以下更改”——这是唯一快速验证方向的依据 - 发现方向错误，别点“部署”或“运行”，直接关窗重开，重新拖拽顺序
字段类型一样，却标成“修改”，大概率是 COLLATE 或 CHARACTER SET 不同
常见现象：两个表字段名、类型、长度完全一致，Navicat 却标黄色“修改”，点开 DDL 比较 标签一看，只有 COLLATE utf8mb4_0900_as_cs 和 COLLATE utf8mb4_unicode_ci 的区别。这类差异不影响业务逻辑，但会触发 ALTER TABLE ... CONVERT TO CHARACTER SET，可能锁表或引发隐式转换。
实操建议：
- 每条差异项都点开，到底部
DDL 比较标签逐行盯：CHARACTER SET、COLLATE、COMMENT、ENGINE - 确认是元数据无关差异后，右键该条目 → “忽略此项”；Navicat 不支持批量忽略或按规则过滤，必须手动点
- 别依赖“忽略默认值”或“忽略列顺序”这类全局选项——它们对 COLLATE 无效
只勾选“表”，漏掉视图/触发器，上线就报错
默认情况下，Navicat 结构同步只对比 TABLE 和 COLUMN。但很多关键变更藏在视图定义里：比如新版本视图少了一个 SELECT 列，或者触发器逻辑改了条件，而你只盯着表结构，上线后查不到数据才追查，已晚。
实操建议：
- 在“对象选择”页，务必手动勾选
Views、Triggers、Stored Procedures（除非你明确知道它们没变） - 如果只关心表结构，也建议先全选跑一次比对，再根据结果反向取消无关项——比凭经验跳过更可靠
- 注意：视图/存储过程的 DDL 差异常因注释、空格、换行误报，若确认无实质变更，再右键忽略
导出 SQL 后执行报错 ERROR 1064，大概率是缺分号
Navicat 预览页右上角的“导出 SQL 文件”按钮，导出的内容默认**没有分号结尾**。直接丢进 MySQL 客户端执行，第一句就报 ERROR 1064。
实操建议：
- 导出后，用编辑器全局替换
\n为;\n（注意保留换行） - 或者，在预览页点“高级”标签页，勾选“每条语句后添加分号”——这个选项藏得深，不点就默认不加
- 另外检查开头是否有
SET FOREIGN_KEY_CHECKS=0：若目标库有外键级联，这句可能导致后续ALTER TABLE失效，建议删掉，末尾补SET FOREIGN_KEY_CHECKS=1
最易被忽略的是：Navicat 从不校验你选的两个库是否真的兼容。MySQL 5.6 和 8.0 混用时，JSON 字段、隐藏索引等特性会静默丢失，而界面毫无提示。比对前务必确认两端版本在 Navicat 支持列表内，且连接用户具备 LOCK TABLES 权限——缺它，比对会卡死在“正在获取表元信息”。
