数据库迁移流水线

解决什么问题

数据库结构变更往往依赖手写 ALTER TABLE，一旦上线出错，回滚窗口极短。真实项目里更棘手的是：users 表被多个服务共用，加一列可能拖慢写入，改一个约束可能让线上查询直接报错。这个技能把模式变更纳入版本化流程，让 agent 像管理代码一样管理数据库演进。

技能如何工作

核心能力：

• 按技术栈选择迁移框架：Alembic（Python/SQLAlchemy）、Prisma Migrate（TypeScript/Node）、Flyway（Java/SQL）、Knex（JavaScript/Node）
• 生成包含升级与降级逻辑的迁移脚本，并在支持的场景下用 autogenerate 自动检测变更
• 区分向后兼容（扩展）与破坏性（收缩）变更，据此制定部署策略
• 通过扩展与收缩分阶段推进生产部署，保证零停机
• 集成 CI/CD：在预发环境验证迁移与回滚，在流水线中对一次性数据库运行迁移

关键步骤：

1. 评估变更：分析请求的模式改动，分类为新增还是破坏性
2. 选择工具并初始化：匹配项目技术栈，确认框架已连接到目标数据库
3. 生成并审查脚本：自动生成迁移后逐行检查，显式补上 down 逻辑
4. 预发验证：在镜像生产数据的库上应用迁移，运行测试套件并验证回滚
5. 分阶段部署：先扩展结构 → 部署双写代码 → 填充数据 → 切换新代码 → 收缩旧结构，每步都可安全回滚
6. 验证与监控：核对版本表状态，观察日志与数据库性能

适用边界与注意点

• 自动生成不等于可直接执行：重命名字段常被识别为删除+新增，必须审查生成的 SQL，必要时用 op.alter_column() 或原生 ALTER TABLE ... RENAME COLUMN
• 大表迁移需特别处理：旧版 PostgreSQL 上加带默认值的 NOT NULL 列可能锁表数分钟，建议先设可空、分批填充再收紧约束
• 并发迁移要有锁机制：多实例部署时确保只有一个实例执行迁移，可借助 Flyway 与 Alembic 的咨询锁
• 事务支持因库而异：PostgreSQL 的 DDL 可回滚，MySQL 不行，需提前设计部分失败的恢复方案
• 枚举变更要绕开限制：PostgreSQL 枚举加值是非事务操作，建议新建类型、迁移列、再删旧类型