Navicat「结构同步」是面向部署的DDL变更生成器，非静态比对工具；必须确认左侧为源库、右侧为目标库，且状态栏显示“将对test_old应用以下更改”；所有差异须逐条点开「DDL比较」核对COLLATE、字符集等细节，手动忽略无关项；索引差异需通过「在DDL比较中查看」识别；预览SQL需删SET FOREIGN_KEY_CHECKS=0并补1，ENUM修改应避免全量重建，导出SQL须补分号；操作前须备份目标库并确认用户含LOCK TABLES权限。
结构同步不是比对工具，而是变更脚本生成器
Navicat 的「结构同步」本质是面向部署的 DDL 变更生成流程，不是静态比对工具。你点「比对」看到的差异，直接取决于源库和目标库的方向选择——选反了，它就默认要删掉源库才有的字段，而不是给目标库加字段。结构同步 界面不标“源/目标”，只写“数据库1”“数据库2”，但逻辑上：左侧是源（基准，如 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无效
索引差异藏得深，不看 DDL 比较根本发现不了
Navicat 把索引当整体对象比：名字不同就标「删除+新建」，但字段顺序变了、前缀长度变了（如 col_b(10) vs col_b）、ASC/DESC 排序方向变了，全都不会单独列出，只在「DDL 比较」里暴露。
- 右键任意索引相关差异项 → 「在 DDL 比较中查看」，才能确认是不是字段顺序调换
- MySQL 8.0+ 的函数索引（如
KEY ((UPPER(email)))）必须两边写法一字不差，否则直接报不一致，且函数体差异不被高亮 - 跨库比对时，若两张表
COLLATE不同，Navicat 会判定索引「需重建」——这不是 bug，是真实风险：排序规则变，索引可能失效
执行前必须人工验证 SQL，不能直接运行预览页内容
预览页默认生成的 SQL 包含 SET FOREIGN_KEY_CHECKS=0，但若目标库存在外键级联约束，该语句可能导致后续 ALTER TABLE 失效；建议手动删掉这两行，结尾补上 SET FOREIGN_KEY_CHECKS=1。
-
ENUM字段新增值，Navicat 默认用MODIFY COLUMN重建整个字段，线上大表务必替换成ALTER TABLE t1 MODIFY COLUMN status ENUM('a','b','c','d') NOT NULL形式 - 导出 SQL 文件后，内容不含分号结尾，执行时报错
ERROR 1064；必须打开文件全局替换\n为;\n，或在 Navicat 执行前勾选「每条语句后添加分号」（该选项藏在「高级」标签页里） - 目标库必须提前备份，
结构同步不校验数据一致性，只管结构；误选反向方向，DROP TABLE会直接执行
LOCK TABLES——缺这个权限，比对会卡死在「正在获取表元信息」；还有就是 MySQL 5.6 与 8.0 混用时，JSON 字段、隐藏索引等特性会静默丢失，界面不报错也不提示。 
