结构同步前必须确认三件事：目标库已完整备份且可还原；源库结构变更已完成测试、无未合并分支；两库字符集、排序规则、存储引擎一致。
结构同步前必须确认的三件事
navicat 的结构同步不是“一键覆盖”，而是生成可审阅的 sql 脚本，执行权完全在你手上。直接运行同步脚本可能删表、改字段、丢数据，所以动手前必须确认：
- 目标库（生产库）已完整备份，且备份可验证还原
- 源库（预发布库）结构变更已完成测试，无未合并的开发分支残留
- 两个库的字符集、排序规则、存储引擎（如 InnoDB vs MyISAM）一致，否则同步脚本会报错或行为异常
特别注意：utf8mb4_unicode_ci 和 utf8mb4_general_ci 看似兼容，但 Navicat 比对时会当作差异处理；ENGINE=InnoDB 若目标库默认引擎是 MyISAM，ALTER 语句会失败。
用“结构同步”功能比对并生成脚本
这不是数据同步，而是 DDL 层面对齐。操作路径固定：右键预发布库 → 工具 → 结构同步 → 选中生产库 → 开始比对。
关键控制点：
- 勾选「忽略注释」和「忽略外键名称」，避免因注释格式或 FK 命名习惯不同产生大量假差异
- 取消勾选「比较表选项」里的「AUTO_INCREMENT 值」——生产库主键自增位置不能被预发布库覆盖
- 如果预发布库有新增索引，但生产库已有同名列的冗余索引，Navicat 不会自动删除后者，需人工判断是否保留
生成的脚本里，DROP INDEX 和 RENAME TABLE 操作默认被禁用，必须手动启用——因为这类操作风险高，Navicat 强制你二次确认。
同步脚本执行前的最小化验证
别跳过这步。直接在生产库执行脚本前，先做两件事：
- 把生成的脚本复制到新查询窗口，在生产库上执行
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';再运行 —— 避免因 strict mode 导致字段长度超限等报错中断 - 对涉及
ALTER TABLE ... MODIFY COLUMN的语句，单独抽出来，在测试库上跑一遍EXPLAIN FORMAT=TREE查看是否触发全表重建（尤其大表） - 检查脚本里是否有
CREATE TABLE IF NOT EXISTS—— 这类语句在生产环境可能掩盖表已存在但结构不一致的问题，建议改成显式CREATE TABLE+ 手动确认
Navicat 不校验语法兼容性。比如预发布库用 MySQL 8.0 的 JSON_CONTAINS_PATH()，而生产库是 5.7，脚本照样生成，但执行必报错。
为什么不能用“数据同步”代替结构同步
有人试图用数据同步功能“覆盖”结构，这是危险误区。数据同步只处理行级数据，它：
- 不会创建缺失的表或字段，只会报错退出
- 遇到目标表字段少于源表时，直接失败，不提示缺哪些列
- 若目标表多出字段，会静默跳过该字段，导致数据丢失不报警
- 对
ENUM或SET类型，值列表顺序稍有不同就判定为不兼容，退化为全量重写
结构同步和数据同步是两条独立路径，目的不同、机制不同、失败表现也不同。混用等于放弃控制权。
真正要命的是：Navicat 的结构同步不记录执行日志，也不保存历史版本。每次比对都是从当前状态出发，没有回滚锚点。所以每次同步后，务必手动存档生成的脚本文件，并标注时间戳和变更摘要。
