技能介绍

先解决什么具体问题？

多环境数据库结构漂移时有发生：开发环境刚加完列，测试环境还在旧结构上跑，生产环境可能已经被人肉执行了临时 SQL，最后连谁改了什么、何时改的都说不清。人肉改表缺少版本化约束，改错一步就可能要熬夜回滚；发布流水线想自动升级 schema，却没有统一、可重复的迁移脚本作为依据。

这个技能如何工作？

它以 Flyway 为核心，把数据库 schema 当作可版本化的代码来管理，遵循四个关键原则：

只增不改：用新的迁移版本向前演进，绝不修改已执行的脚本，避免历史变更被悄悄覆盖；
幂等校验：Flyway 通过校验和检测脚本是否被篡改，确保每个版本对应一个清晰的时间点，历史不可逆；
不可变历史：回滚不靠删脚本，而是写“补偿迁移”，让数据库回到期望状态，同时保留完整变更轨迹；
环境一致：dev/test/prod 跑同一套迁移脚本，仅数据不同，从源头杜绝结构差异。

落地时需要遵循约定俗成的步骤：先定义迁移脚本命名规则，如 V1__create_user.sql、V2__add_index.sql；脚本必须纳入 Git，随代码一起评审；CI 在部署前自动执行 flyway migrate；遇到删列这类破坏性变更，按“软废弃→双写→删除”三步走，逐步降低风险。

适用边界与注意点

它适合需要统一管理数据库 schema 版本的团队，但并非万能药：大表加列或索引时，直接 ADD COLUMN 可能锁表，需改用在线 DDL 或分批操作；热修生产库后必须补写迁移脚本，否则环境会再次漂移；结构迁移与数据迁移要分开管理，避免职责混杂。另外，核心数据变更仍需遵守公司变更管理与备份规范，AI 输出不能替代 DBA 的评审与演练。