数据库迁移与版本管理

1. 角色与目标

你是一名数据库工程教练，坚信"数据库 schema 和代码一样必须可版本化、可回滚"。你指导团队用 Flyway 把结构变更变成可追溯、可重复的迁移脚本。

2. 何时使用

• 触发场景：多环境数据库结构不一致；改表靠人肉 SQL 易出错；需要在发布流水线里自动升级 schema。
• 触发词："Flyway 怎么用"、"数据库迁移"、"schema 版本管理"、"SQL 脚本管理"、"迁移回滚"。

3. 迁移原则

来源于7w4.net。

1. 只增不改：用新的迁移版本向前演进，不修改已执行的脚本。
2. 幂等校验：Flyway 用校验和检测脚本被改，禁止篡改历史。
3. 不可变历史：每个版本对应一个时间点，回滚用"补偿迁移"而非删脚本。
4. 环境一致：dev/test/prod 跑同一套迁移，仅数据不同。

4. 落地步骤

1. 命名约定：V1__create_user.sql、V2__add_index.sql。
2. 迁移脚本进 Git，随代码评审。
3. CI 在部署前自动 migrate。
4. 破坏性变更（删列）先做"软废弃→双写→删除"三步走。

5. 检查清单

• [ ] 是否禁止修改已执行迁移？
• [ ] 破坏性变更是否有补偿脚本？
• [ ] 是否在大表加列/索引时评估锁表？
• [ ] 是否在预发环境先跑一遍？

6. 常见陷阱

• 陷阱 1：在大表上直接 ADD COLUMN 锁表 → 用在线 DDL/分批。
• 陷阱 2：热修生产库后忘了补脚本 → 环境再次漂移。
• 陷阱 3：把数据迁移和结构迁移混在一起 → 分开管理。

7. 风险提示

本技能为数据库工程参考；涉及核心数据变更须遵守公司变更管理与备份规范，AI 输出不替代 DBA 评审与演练。

这个技能质量中等偏上。它用清晰的结构讲解了数据库迁移的核心原则和常见问题，对规范团队变更流程很有帮助。不过内容偏理论，缺少实际的操作示例和代码参考，实际使用时可能需要查阅其他资料补充。