必须用模型（Model）代替手动建表，将结构变更固化为可审查、可回滚、可复现的流程：模型生成可Git管理的.ndm文件，支持元信息完整导出；同步需三步确认（预览SQL、人工核对、评审后执行）；外键与索引须显式配置并分离处理；发布后须用Compare Objects校验库与上版SQL的一致性。
不能靠“手动改表+口头同步”来发布数据库版本，必须把结构变更固化为可审查、可回滚、可复现的流程。
用模型（Model）代替直接建表，是流程落地的第一道门槛
很多人一上来就右键“新建表”，填完字段就点执行——这等于跳过了版本控制的起点。真正要支撑团队协作，得从“模型”标签页开始建模，而不是从连接树里直接建表。
- 模型画布上拖出的每张表，本质是一个独立的
.ndm文件，可纳入 Git 管理；直接在库中建的表没有对应文件，无法追踪变更来源 - 模型支持设置字符集、存储引擎、注释等元信息，这些在导出 SQL 时会完整保留，而手工 ALTER 很容易漏掉
COMMENT或COLLATE - 多人协作时，A 修改模型、B 同步模型、C 执行同步脚本——三者操作对象一致，不会出现“模型里有字段，库里没建”的错位
结构同步（Structure Synchronization）不是一键操作，而是三步确认动作
Navicat 的 Structure Synchronization 功能常被误用成“自动补全差异”，但它真正的价值在于把隐性变更显性化。每次同步前，必须人工核对生成的 SQL 脚本。
- 勾选“Compare options”里的
Ignore comments和Ignore auto-increment value，否则 trivial 差异会淹没关键变更 - 务必开启
Preview SQL，检查是否混入了DROP INDEX或MODIFY COLUMN这类高危操作；大表上MODIFY可能锁表数分钟 - 同步目标不能选“立即执行”，应导出为
.sql文件，走团队约定的评审流程（例如 PR + DBA 签字）后再手工执行
外键和索引变更必须拆开处理，不能依赖模型自动推导
模型里拖一根连线，Navicat 会自动生成外键约束，但生产环境往往要求更精细的控制：比如外键要带 ON UPDATE CASCADE，但索引得单独加 UNIQUE 或覆盖索引字段。
- 外键定义必须显式写在模型字段的
Foreign Key标签页里，不能只靠连线——连线只影响 ER 图显示，不参与 SQL 生成逻辑 - 索引要单独在表设计页的
Indexes标签页配置，注意区分PRIMARY、UNIQUE、INDEX类型，Navicat 不会自动优化重复索引 - 如果线上已有数据，新增外键前需确认关联字段值全部存在，否则
ALTER TABLE ... ADD FOREIGN KEY会报ERROR 1452
最易被忽略的是模型与库的实际一致性：模型改了、SQL 脚本执行了、但没人验证库中是否真按预期生效。建议每次发布后，用 Navicat 的 Compare Objects 功能做一次反向校验——不是比模型和库，而是比“当前库”和“上一版导出的 SQL 文件”，这才是真实可信的基线。
