跟踪本地数据库变更以部署到生产环境的最佳实践是什么

解决本地/生产环境数据库结构不一致的核心是把数据库变更纳入和业务代码一致的版本化管理流程，具体实践如下：

1. 引入版本化数据库迁移工具 #

所有结构变更（新增字段、修改字段类型、调整索引等）都要编写可执行的迁移脚本，和业务代码一起存入版本控制系统，每个脚本对应唯一的递增版本号，工具会自动识别未执行的变更并按顺序执行。
常用工具适配不同技术栈：

• 框架内置工具：Django migrate、Ruby on Rails Active Record Migration、Laravel Migration
• Java生态：Flyway、Liquibase
• 通用跨语言工具：Golang Migrate、Sqitch

2. 迁移脚本编写规则 #

• 单脚本对应单一变更：不要把多个不相关的结构调整合并到同一个脚本，降低回滚复杂度
• 必须配套回滚逻辑：每一条正向变更SQL都要写对应的回滚SQL，比如新增字段的回滚操作为删除对应字段，修改字段类型的回滚操作为改回原有类型
• 禁止编写环境绑定逻辑：不要在脚本中写入仅本地/测试环境才有的测试数据、特殊配置
• 数据类变更提前校验：修改字段类型、调整字段约束前先校验存量数据是否符合变更要求，避免执行时触发数据转换错误

3. 上线流程配套约束 #

• 本地开发过程中禁止直接修改数据库结构不提交迁移脚本，所有变更必须落地为可执行的脚本
• 测试/预发环境部署时优先执行迁移脚本，验证功能完全正常后再推进生产上线
• 生产环境执行迁移前必须先完成全量数据库备份，避免不可逆的数据损坏
• 大表结构变更建议在业务低峰期执行，或使用pt-online-schema-change、gh-ost等在线DDL工具，避免锁表影响线上业务

临时兜底方案（未接入迁移工具时） #

如果暂时没有条件接入迁移工具，所有数据库变更操作必须同步记录到统一的变更日志，每条记录包含变更时间、变更SQL、变更目的、回滚SQL四个核心字段，上线前逐条核对待执行的SQL，先在预发环境1:1验证通过后再到生产执行。

内容的提问来源于stack exchange，提问作者SameerUllah