数据库迁移（DB Migrations）

在生产环境中，当新旧代码在发布过程中对数据库 Schema 的理解不一致时，Schema 变更会失败。推荐采用 扩展/收缩（expand/contract） 策略：先引入向后兼容的变更，待系统稳定后再移除旧结构。

何时提供此工作流

触发条件：

• 在生产环境中执行 ALTER TABLE；涉及大表重写（large table rewrites）
• 蓝绿部署（blue/green deploys）与 Schema 状态强耦合
• 需要实现零停机（zero-downtime）或低停机（low-downtime）迁移

初始建议：

采用 六个阶段 流程：(1) 变更分类，(2) 扩展阶段，(3) 回填与双写，(4) 读写切换，(5) 收缩阶段，(6) 验证与回滚。请确认所用数据库引擎（PostgreSQL、MySQL 等）。

阶段 1：变更分类

目标：区分变更类型为“增补型（additive）”还是“破坏型（destructive）”；评估锁表风险（是否引发全表重写 vs 仅元数据瞬时变更）。

退出条件：迁移任务已明确标注为 expand 或 contract 类型，并附有风险说明。

阶段 2：扩展阶段

目标：新增可空列（nullable columns）或新表，且不破坏当前已部署代码的正常运行。

实践建议

• 避免使用会导致某些数据库引擎对大表产生严重锁表现象的 DEFAULT 子句（应改用分阶段回填策略）

阶段 3：回填与双写

目标：以受控速率进行批量回填；在必要时，于过渡期同时向旧结构和新结构写入数据（dual-write）。

阶段 4：读写切换

目标：仅在回填完成后，才部署开始读取新列的代码；使用功能开关（feature flags）实现渐进式发布（staged rollout）。

阶段 5：收缩阶段

目标：确认代码库、日志及功能使用数据中均无对旧列的引用后，再执行删除操作。

阶段 6：验证与回滚

目标：持续监控错误率、慢查询、主从复制延迟等指标；若需回滚，则重新部署上一版应用 + 跳过所有破坏性步骤，直至系统恢复稳定。

最终评审检查清单

• 变更已完成分类；expand/contract 路径清晰明确
• 增补型迁移已在依赖该变更的代码上线前完成
• 回填操作已限速并经验证
• 读写切换已通过功能开关有序编排
• 收缩操作仅在所有引用均已清除后执行
• 监控机制与回滚流程已完成测试

高效指导的小贴士

• 迁移过程中的长事务可能导致服务中断——请将操作切分为小批次（chunk work）。
• 在适用场景下，使用在线 Schema 变更工具（如 pt-online-schema-change 等）。

异常情况处理

• SQLite 或其他嵌入式数据库引擎的锁机制不同——须按具体引擎分别验证。