数据库迁移安全工作流

学完这篇你会掌握什么

• 理解 数据库迁移安全工作流 的核心作用和适用场景
• 掌握 数据库迁移安全工作流 的基本用法和常用参数
• 将数据库 schema 变更拆分为可回退、可观测、可分阶段执行的迁移流程，降低发布期结构变更风险。
• 理解 推荐流程 相关的概念
• 掌握 发布前检查清单 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

数据库迁移失败的代价通常高于应用层发布失败。安全迁移的关键，是把一次不可逆大改拆成多个可控小步骤。

输入

迁移脚本兼容代码回退方案

→expand → backfill → switch read/write → contract

输出

迁移风险降低回滚更可行线上中断更少

先扩展后收缩，是多数生产迁移的保守策略。

先想一个问题

你和团队正在协作一个项目，分支越来越多，合并越来越频繁，但缺少一个稳定的协作节奏——每个人都在用自己的方式同步代码，冲突越来越频繁。

推荐流程

1. Expand：先加新字段/新表，不删旧结构

先让旧逻辑继续工作，避免立即破坏兼容性。

2. Backfill：补历史数据

批量补数要控制速率，避免影响线上性能。

3. Switch：逐步切读写路径

先读新写双写或影子验证，再切换主路径。

4. Contract：确认稳定后清理旧结构

旧字段删除应延后到多个发布周期之后。

发布前检查清单

• 是否有回退脚本或等价回退策略
• 是否有慢查询/锁等待监控
• 是否评估了迁移窗口与流量高峰冲突
• 是否完成了预发数据量级演练

!一次性删旧字段是高风险动作

在未确认全链路已切换完成前，直接删除旧结构会让回滚成本暴增。优先延迟清理，先确保稳定。

常见误区

误区 1：开发环境通过就直接上生产

真实数据规模会放大锁竞争和回填耗时问题。

误区 2：迁移脚本和应用发布强绑定

应允许迁移先行、应用后切换，避免耦合失败。

误区 3：回退方案只写“必要时回滚”

没有具体动作步骤的回退方案等于没有方案。

→为下一次 schema 变更做迁移分解

1. 写出 expand/backfill/switch/contract 四阶段动作。
2. 定义每阶段可观测指标。
3. 写明每阶段失败后的回退动作。
4. 在预发用接近生产体量数据演练一次。

接下来建议继续看什么

1. Code freeze and release candidate workflow
2. Release branch workflow
3. Hotfix rollback after release

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• 跨仓库集成工作流
• 功能分支协作流
• Feature Flag 渐进发布工作流