Navicat的「结构同步」不是版本控制，它仅支持单次比对与手动执行DDL，不记录历史、不生成可提交SQL、不关联Git分支；真正数据库模式版本控制需满足变更可追溯、SQL可入Git、执行可重复三大条件。
Navicat 的「结构同步」不是版本控制，别混淆
navicat 自带的 结构同步 功能（structure synchronization）本质是单次比对 + 手动执行 ddl 变更，它不记录历史、不生成可提交的 sql 文件、也不关联 git 分支。把它当版本控制用，等于拿剪刀当 git —— 能剪，但剪完不知道谁剪的、为什么剪、上一刀在哪。
真正能落地的数据库模式版本控制，必须满足三个条件：变更可追溯、SQL 文件可纳入 Git、执行过程可重复。Navicat 本身不提供这整套流程，但它可以作为辅助工具参与其中。
用 Navicat 导出结构为可版本化的 SQL 文件
关键动作是导出「干净、幂等、带注释」的 DDL，而非直接用「备份」或「转储」功能。
右键数据库 → 转储 SQL 文件 → 选择“结构”（不勾选“数据”）- 在导出设置中关闭
导出 AUTO_INCREMENT 值和导出触发器/事件（除非你明确要版本化它们） - 勾选
添加 DROP 语句：确保每次执行都是重建式，避免残留字段干扰 - 手动重命名导出文件为
v20260728_add_user_status_column.sql这类带日期+语义的格式，方便 Git 提交时理解意图
注意：Navicat 导出的 SQL 默认不含事务包装（BEGIN; ... COMMIT;），若需强一致性，得手动加，或改用 mysqldump --no-data --skip-triggers 等命令行工具补位。
Navicat 如何配合 Git 工作流
核心原则：Navicat 不管理 Git，只负责「生成」和「验证」两个环节。
- 开发新字段时，先在 Navicat 中设计表 → 查看
DDL 标签页复制出 CREATE/ALTER 语句 → 手动保存为001_add_phone_to_users.sql→ 提交到 Git - 上线前，在测试库用 Navicat 执行该 SQL，再用
结构同步对比生产库与测试库结构差异，确认无意外变更 - 回滚依赖 Git 历史：不要靠 Navicat「撤销」，而是 checkout 上一版 SQL 文件重新执行（前提是你的 DDL 是幂等或含反向逻辑）
- 多人协作时，禁止直接在 Navicat 里点「同步到生产库」——所有变更必须经 Git PR 审核后，由部署脚本执行
容易被忽略的兼容性陷阱
Navicat 导出的 SQL 在不同 MySQL 版本间可能不兼容，尤其涉及 JSON、Generated Column、Collation 设置等。
- 导出前确认目标环境 MySQL 版本，在 Navicat 连接属性中设置
MySQL Server Version（如8.0.33），否则可能导出 5.7 不支持的语法 - 使用
utf8mb4_0900_as_cs这类 8.0+ 排序规则时，Navicat 会原样导出，但老版本 MySQL 会报错Unknown collation - PostgreSQL 用户注意：
pg_dump --schema-only比 Navicat 导出更可靠，Navicat for PostgreSQL 的 DDL 有时漏掉OWNER或SECURITY DEFINER属性
真正卡住团队的往往不是工具会不会用，而是导出的 SQL 能不能在 CI 环境里静默跑通 —— 这需要把 Navicat 当作「SQL 起草器」，而不是「部署引擎」。
