1. Flyway 概述
1.1 Flyway 是什么
Flyway 是一款开源的数据库版本控制与迁移工具，由 Axel Fontaine 于 2010 年创建，现由 Redgate 公司维护。它采用“约定优于配置”的设计哲学，通过简单的文件命名规则和版本号机制，将数据库 Schema 的变更纳入 Git 等版本控制系统，实现数据库与应用代码的同步演进。
Flyway 的核心工作模式是：在目标数据库中创建一个元数据表（默认名为 flyway_schema_history），记录每次已执行的迁移脚本及其校验和。当应用启动时，Flyway 自动扫描指定路径下的迁移脚本，与元数据表对比，按版本号顺序执行尚未运行过的脚本，从而保证数据库状态与代码仓库中的脚本集合保持一致。
核心定义：Flyway 是一个数据库迁移（Database Migration）工具，它让数据库 Schema 的变更像应用代码一样可追溯、可回放、可协作。
1.2 核心价值
Flyway 为数据库变更管理带来的核心价值体现在以下五个维度：
| 维度 | 价值描述 | 关键收益 |
|---|---|---|
| 版本可追溯 | 每次数据库变更都对应一个唯一的版本号，记录在元数据表中 | 可随时查询数据库当前处于哪个版本，谁在什么时间执行了什么变更 |
| 自动化执行 | 应用启动时自动检测并执行未应用的迁移脚本 | 消除人工执行 SQL 脚本的遗漏风险，提升部署效率 |
| 团队协作 | 迁移脚本存储在 Git 仓库中，团队成员共享同一套变更历史 | 解决多人开发时数据库 Schema 不一致的痛点 |
| 幂等与可重复 | 已执行的脚本不会重复执行，校验和机制防止脚本被篡改 | 确保同一套脚本在开发、测试、生产环境产生相同结果 |
| 回滚支持 | 通过编写撤销迁移（Undo Migration）脚本实现版本回退 | 降低因错误变更导致的生产事故恢复成本 |
1.3 与传统数据库脚本管理的对比
传统数据库脚本管理方式通常依赖 DBA 手动执行 SQL 文件、通过邮件或文档传递变更说明，或者使用简单的数据库客户端工具逐个运行脚本。这种方式在团队规模扩大、部署频率提升后暴露出大量问题。下表从多个关键维度进行对比：
| 对比维度 | 传统脚本管理 | Flyway 管理 |
|---|---|---|
| 版本记录 | 依赖文件名或文档人工记录，容易遗漏 | 自动写入元数据表，版本号、校验和、执行时间完整记录 |
| 执行顺序 | 需要人工按顺序执行，容易搞错顺序 | 按版本号自动排序执行，严格保证顺序 |
| 重复执行 | 脚本可能被重复执行导致错误 | 已执行脚本自动跳过，不会重复运行 |
| 团队协作 | 多人同时修改 Schema 时冲突频发 | 脚本纳入 Git 管理，通过版本号解决冲突 |
| 环境一致性 | 开发、测试、生产环境脚本版本难以对齐 | 同一套脚本在所有环境执行，结果一致 |
| 回滚能力 | 需要手动编写逆向 SQL，风险高 | 支持 Undo Migration，可编程回滚 |
| CI/CD 集成 | 难以集成到自动化流水线 | 提供命令行、Maven/Gradle 插件、API 等多种集成方式 |
常见误区：部分团队认为使用 Git 管理 SQL 文件就等同于数据库版本控制。实际上，如果没有 Flyway 这样的工具来记录执行状态和校验和，Git 只能管理文件版本，无法保证数据库的实际状态与脚本一致。
1.4 适用场景
Flyway 适用于以下典型场景：
- 微服务架构：每个微服务拥有独立数据库，需要独立管理各自的 Schema 版本，Flyway 的轻量级特性非常适合嵌入到每个服务中。
- 持续交付/持续部署（CI/CD）：在 Jenkins、GitLab CI、GitHub Actions 等流水线中集成 Flyway，实现数据库变更的自动化发布。
- 多环境管理：开发、测试、预发布、生产环境需要保持数据库 Schema 一致，Flyway 确保每个环境执行相同的迁移脚本序列。
- 团队协作开发：多个开发人员同时修改数据库结构时，Flyway 的版本号机制和冲突检测能力可有效减少协作摩擦。
- 数据库重构与演进：对已有数据库进行增量式改造，每次变更作为一个独立版本，降低重构风险。
- 合规与审计：金融、医疗等监管严格的行业，需要完整的数据库变更审计记录，Flyway 的元数据表提供了天然的审计日志。
选型建议：如果你的项目满足以下任意一条，Flyway 都是一个值得考虑的选项：① 数据库变更频率超过每月一次；② 团队人数超过 3 人；③ 需要对接 CI/CD 流水线；④ 有合规审计要求。对于极简单的单机应用或原型阶段项目，传统脚本管理可能暂时够用，但建议尽早引入 Flyway 以避免技术债务积累。