Navicat结构同步不识别Sprint等业务概念，必须人工界定范围：通过统一前缀/独立Schema隔离对象，或在「选择对象」页手动勾选本次迭代表；务必用Generate SQL生成可审脚本，禁用直接Run，再按Sprint编号命名保存并添加注释。
Navicat 本身不支持“按 Sprint 自动分组变更”或绑定项目管理周期，所谓“Sprint 变更脚本”必须靠人工界定范围 + 手动触发结构同步 + 严格控制生成与执行流程来实现。
如何限定同步范围只包含本次 Sprint 的表和对象？
Navicat 的结构同步（Structure Synchronization）不识别业务语义，它只比对两个数据库的当前 DDL 状态。所以“本次 Sprint 的变更”必须由你提前落实为具体的数据库对象集合：
- 在开发库中，把本次 Sprint 涉及的所有表、视图、索引、存储过程等对象，统一加前缀（如
sprint_23）或归入独立 Schema（如sprint_v23），再将该 Schema 作为源库参与同步 - 若无法改名或建新 Schema，就用 Navicat 的「对象过滤」功能：在同步向导第二步「选择对象」界面，取消勾选无关表，只保留本次迭代明确要变更的那几张 —— 这一步不能跳过，否则脚本会包含历史残留差异
- 避免依赖“上次同步时间戳”或“Git 提交记录”，Navicat 不读取这些元数据，它只看当前结构快照
为什么直接点 Run 后脚本不可控，必须走 Generate SQL？
点 Run 是让 Navicat 自动执行差异计算 + 即时 DDL 执行，全程不暴露语句。这对快速验证有害无益，尤其在敏捷迭代中，你常需要：
- 在脚本开头手动加
BEGIN TRANSACTION和COMMIT，防止多表变更中途失败导致状态不一致 - 把高风险语句（如
MODIFY COLUMN缩容、DROP INDEX）单独拎出来，补上数据校验逻辑或拆成两步 - 替换目标库名或表前缀（比如从
dev_users改成prod_users），而Generate SQL窗口允许全文编辑 - 注意：
Generate SQL按钮在同步对比窗口右上角，不是主界面上那个大大的Run；点了Run就真执行了，没备份就只能靠 binlog 回滚
生成的脚本为什么不能直接用于生产环境？
Navicat 输出的 DDL 脚本是“技术可行但业务冒进”的典型：
- 对主键重命名，它默认生成
DROP INDEX old_pk; CREATE INDEX new_pk，不处理外键依赖，可能让下游服务瞬间报错 - 字段类型变更（如
VARCHAR(255) → VARCHAR(50)）不会自动加USING子句或数据截断检查，脚本跑通 ≠ 数据安全 - 分区表、全文索引、Generated Column 等对象压根不会出现在同步列表里，脚本里自然没有，但 Sprint 需求里若有这类变更，必须退出向导，手工补写
- 脚本中字段定义顺序、约束声明顺序是 Navicat 自行解析排布的，和源库原始建表语句不一致 —— 这不影响执行，但会干扰你用
diff工具做版本比对
如何让每次 Sprint 的脚本可追溯、可复用？
Navicat 不保存你改过的脚本，也不记录哪次同步对应哪个需求编号。要建立轻量级追踪机制，得靠外部约定：
- 每次点击
Generate SQL后，立刻保存为本地文件，命名含 Sprint 编号和日期，例如sprint-23-20260907.sql - 在文件头部加注释，写明变更目的、影响表、是否含数据迁移、回滚步骤（哪怕只有一句
-- DROP TABLE IF EXISTS temp_migration_log;） - 执行前，把该 SQL 文件拖进 Navicat 的
Query标签页运行，而不是回同步窗口点任何按钮 —— 这样执行日志会留在 Query 历史里，且你能看到每条语句的耗时和影响行数 - 如果多个 Sprint 共用同一套库结构，建议每次同步前先用 Navicat Data Modeler 导出当前物理模型为
.ndm文件，它比 SQL 更稳定，能存下注释、关系线、字段描述等上下文
真正卡住敏捷节奏的，从来不是 Navicat 功能少，而是误以为“点一下就能同步”，结果在生产库上执行了未经审查的脚本。脚本可控的前提，是你始终掌握生成入口、编辑出口和执行入口这三个分离环节。
