结构同步比导出SQL更可靠省事，能自动比对差异、生成可审阅语句且不碰数据；使用前须确认连接有效、权限充足、目标库非只读；比对时需勾选Compare comments等关键选项；生成SQL须人工审核，推完要验证注释和索引。
直接用「结构同步」功能，比导出再执行 sql 更可靠、更省事。它能自动比对差异、生成可审阅的变更语句，且不碰数据——这才是推结构该有的样子。
结构同步前必须确认的三件事
很多人点完“比对”就失败，问题其实不出在 Navicat，而在前置条件没卡死：
- 源库和目标库必须已建立连接，且连接名在 Navicat 导航窗格中可见（不能是临时连接）
- 目标库账号至少要有
CREATE、ALTER、DROP权限；若含外键或视图，还需REFERENCES和SHOW VIEW - 目标库不能处于只读模式（如 MySQL 的
read_only=ON），否则即使权限全开也会报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option
比对时关键选项怎么选
点击「工具 → 结构同步」后，进入比对界面。这里几个勾选项直接影响最终 SQL 是否可用：
- 务必勾选
Compare comments：否则字段注释（COMMENT）不会参与比对，推上去就丢说明 -
Ignore auto-increment value建议勾选：避免因主键自增起始值不同触发无谓变更 -
Use IF NOT EXISTS for CREATE TABLE勾选：防止目标库已有表时执行失败；但注意 MySQL 5.7 及以下版本不支持该语法，得手动删掉 - 不要勾选
Drop objects not exist in source：除非你明确要清空目标库中多出的表/视图，否则极易误删
生成的 SQL 必须人工过一遍再执行
Navicat 生成的变更脚本不是“拿来即用”的黑盒，尤其在团队测试机上：
- 检查是否有
DROP TABLE或ALTER TABLE ... DROP COLUMN—— 这类操作不可逆，需提前备份或确认测试环境允许 - 留意外键约束名是否一致：如果源库用的是 Navicat 自动生成的
fk_20260613_xxx，每次导出都变，会导致 Git 提交冲突；建议先在模型里统一设成固定名，如fk_order_user_id - 若目标库是低版本 MySQL（如 5.6），生成的
JSON字段或GENERATED COLUMN语句会报错，得手动替换成等效逻辑
推完别忘了验证字段注释和索引状态
结构同步成功不代表万事大吉。两个最容易被忽略的点：
- 字段注释是否落地？执行
SHOW FULL COLUMNS FROM table_name，看Comment列是否非空；若为空，说明导出时没勾选Compare comments，或目标库字符集不兼容（如latin1存中文注释会变乱码） - 索引是否完整？特别是联合索引顺序、前缀长度（如
INDEX idx_name (name(191))），Navicat 有时会漏掉括号里的长度声明，导致索引失效
真正麻烦的从来不是“怎么推”，而是“推完谁来兜底”。结构同步生成的 SQL 是一次性的快照，没有回滚机制，也没有版本追踪。如果你的测试机要反复重置，建议把每次同步生成的 SQL 手动存进 Git，并在文件头写明来源库、时间、变更人——不然下次有人问“这个字段注释怎么没了”，你翻三天日志也找不到源头。
