Navicat 不具备版本控制能力，需作为 DDL 生成器和结构验证器嵌入 Git 流程；其同步功能无变更记录、不可审计、不支持 diff 与自动化校验，故 Sprint 变更必须固化为命名规范的 SQL 文件并由 CI/CD 执行。
Navicat 本身不提供版本控制能力，但可以作为「DDL 生成器 + 结构验证器」嵌入 Git 驱动的数据库变更流程——关键在于把每次结构变更固化为可审查、可回放的 SQL 文件，而不是依赖 Navicat 的图形操作同步。
为什么不能直接用 Navicat 同步功能管理 Sprint 版本？
Navicat 的「结构同步」是即时执行型工具，它不记录变更意图，也不保留历史快照。多人并行开发时，A 在 Navicat 里点一下「同步到测试库」，B 可能正改着同一张表的字段顺序，结果就是：
- 没有 commit message 说明“为什么加这个字段”
- 无法 diff 两个 Sprint 之间的结构差异（比如 v1.2 和 v1.3）
- 上线前无法做自动化校验：目标库是否真的已执行过该变更？
- 回滚只能靠人肉找上一个版本的 Navicat 备份，不可靠且无审计依据
每个 Sprint 对应一个 DDL 文件：命名与生成规范
在 Navicat 中设计完新字段或索引后，不要点「同步」，而是切换到 DDL 标签页复制语句，保存为带语义的文件名：
- 文件名格式：
YYYYMMDD_sprint-{n}_{desc}.sql（例如：20261015_sprint-42_add_status_to_orders.sql） - 必须包含完整
ALTER TABLE或CREATE TABLE，避免只写MODIFY COLUMN这类隐含上下文的语句 - 如果涉及视图/存储过程，用
SHOW CREATE VIEW手动获取原始定义，再粘贴进文件——Navicat 自动生成的常带DEFINER或多余注释 - 所有文件统一放在项目根目录下的
db/migrations/目录，纳入 Git 管理
上线前用 Navicat 验证结构一致性
部署脚本执行完 DDL 后，别信日志“执行成功”，要用 Navicat 做二次校验：
- 在测试库执行完该 Sprint 的全部 SQL 后，用 Navicat 的「结构同步」功能，将测试库设为源，生产库设为目标（注意勾选
Compare only） - 重点看「差异预览」窗口里有没有意外项：比如 Navicat 自动加了
LOCK=NONE（MySQL 5.7 不支持）、或把utf8mb4_0900_as_cs写进语句（老版本报错） - 若发现差异，不是改 Navicat 设置，而是回到 SQL 文件里手动修正——因为最终上线的是这个文件，不是 Navicat 的同步逻辑
- 确认无差异后，截图保存「同步对比报告」，作为本次发布的 DB 变更附件
回滚和协作必须绕开 Navicat 的「撤销」按钮
Navicat 的「撤销上一步」只作用于当前连接会话，对已提交的事务无效，也留不下任何痕迹。真实回滚必须基于 Git 历史：
- 要回退 Sprint-42 的变更，就 checkout 上一个版本的
db/migrations/目录，找到上一版 SQL（如20261008_sprint-41_...），检查它是否包含反向逻辑（DROP COLUMN或ALTER TABLE ... DROP INDEX） - 多人协作时，禁止任何人直接在 Navicat 里右键「同步到生产库」——所有变更必须走 CI/CD 流水线，由部署脚本按顺序执行
db/migrations/下的文件 - 如果某次同步失败卡在中间，不要在 Navicat 里手动补执行，而应从失败点重新运行整个脚本（幂等性设计很重要，比如用
CREATE TABLE IF NOT EXISTS）
最易被忽略的一点：Navicat 的「结构同步」对比结果，受连接时指定的 MySQL 兼容模式影响极大。同一个库，用 Navicat 连接参数里选「MySQL 8.0」和「MySQL 5.7」做对比，生成的差异列表可能完全不同——所以验证环节必须确保 Navicat 连接的目标库实际版本与生产环境一致，并在「高级」设置中显式启用对应兼容模式。
