发布中的数据库迁移是什么
应用发布与库结构变更分开管理：迁移脚本进版本库、带版本号与校验和、可重放；上线顺序按兼容窗口设计——先迁移（新结构能被旧代码容忍），再发新代码，破坏性动作拆到后续版本。数据库没有一键回滚，所以向前修复为主、结构回滚脚本仅作兜底是默认策略。关注两个数字：迁移在生产环境的执行时长与锁持有时间，两者都应在预发实测并写进发布单。
基本信息
| 工具 | Flyway、Liquibase、dbmate、Alembic 等（版本号+校验和） |
|---|---|
| 顺序 | 兼容态设计下：先迁移（可被旧代码容忍）→ 再发新代码；破坏性变更拆多步 |
| 回滚 | 优选向前修复；结构回滚脚本仅作兜底 |
| 执行方式 | 迁移在流水线单独阶段执行，用独立账号，权限与业务账号分离 |
三步上线顺序
| 步骤 | 动作 | 兼容要求 |
|---|---|---|
| 第 1 步 | 执行迁移 | 新结构对旧代码透明 |
| 第 2 步 | 发布新代码 | 读写开始使用新结构 |
| 第 3 步 | 清理旧结构 | 观察期满且无回退需求 |
典型使用场景
- 常规迭代：新加列、加表随版本发布，先上结构后灌数据
- 大表结构变更：拆成多个版本执行，回填分批限速，避免锁表拖垮线上
- 紧急修复：先核对迁移是否已应用，防止重复执行
- 多环境对齐：staging 先跑一遍，校验执行时长与校验和再放行生产
- 数据修复类 DML：同样走迁移管道，留审计记录而不是手工执行 SQL
- 回退窗口内保持双兼容：旧代码配新结构、新代码配旧结构都要能正常服务
迁移目录示例
迁移目录示例
# 一个文件一个动作，文件名带时间戳排序
db/migrations/
20261001_add_order_ref.sql
20261005_backfill_order_ref.sql
20261010_drop_legacy_column.sql
# 检查已应用版本与状态（Flyway 示例）
# flyway -url=jdbc:mysql://db:3306/app info删除列或改类型前确认无代码引用（含历史版本回滚所需）：回滚窗口内结构必须双兼容。
校验和是防篡改与防乱序的关键：执行过的迁移文件不应再改，需要调整就发新迁移，而不是修改旧文件。