1. Flyway 概述
1.1 Flyway 的定义
Flyway 是一款开源的数据库迁移工具，采用版本化、可重复、幂等的脚本管理方式，将数据库 Schema 的变更纳入软件工程的版本控制体系。它通过约定优于配置的原则，自动扫描指定目录下的迁移脚本，按版本号顺序执行，并记录每次迁移的状态，确保数据库结构从任意历史版本都能安全、可追溯地演进到目标版本。
核心定义：Flyway = 数据库的 Git + Maven。它让数据库变更像代码一样可版本管理、可回滚、可协作。
1.2 核心价值
Flyway 解决了数据库变更管理中长期存在的痛点，其核心价值体现在以下五个维度：
| 维度 | 价值描述 | 关键收益 |
|---|---|---|
| 版本控制 | 每个迁移脚本都有唯一版本号，按序执行，历史可追溯 | 消除“谁改了数据库”的混乱 |
| 自动化 | 集成到 CI/CD 流水线，无需人工登录数据库执行 SQL | 减少人为失误，提升交付效率 |
| 幂等性 | 同一脚本只执行一次，重复运行不会产生副作用 | 支持多次部署，环境间安全同步 |
| 可重复性 | 开发、测试、生产环境执行同一套脚本，结果一致 | 消除环境差异导致的 Bug |
| 团队协作 | 多人并行开发，通过版本号解决冲突，合并后自动执行 | 提升团队数据库变更效率 |
1.3 与传统数据库脚本管理的对比
传统方式通常依赖 DBA 手动执行 SQL 脚本，或使用简单的 SQL 文件集合，缺乏版本追踪和自动化校验。以下对比表清晰展示了两者的差异：
| 对比维度 | 传统脚本管理 | Flyway 管理 |
|---|---|---|
| 执行方式 | 手动登录数据库，按文档顺序执行 | 自动扫描、按版本号顺序执行 |
| 版本追踪 | 依赖文件名或文档记录，容易遗漏 | 内置 flyway_schema_history 表，精确记录每次迁移 |
| 重复执行 | 重复执行可能导致数据丢失或报错 | 幂等设计，已执行的脚本自动跳过 |
| 回滚能力 | 需要手动编写逆向 SQL，风险高 | 支持可撤销迁移（Undo），或通过版本回退重建 |
| 团队协作 | 容易冲突，合并困难 | 版本号机制天然支持并行开发 |
| CI/CD 集成 | 需要额外脚本或人工触发 | 原生支持 Maven、Gradle、命令行、API 集成 |
实践建议：如果团队目前仍在使用“SQL 文件 + 文档 + 手动执行”的方式，建议优先从 Flyway 的基线（Baseline）功能开始过渡，无需清空已有数据库。
1.4 适用场景
Flyway 适用于所有需要管理数据库 Schema 变更的软件项目，尤其在以下场景中表现突出：
- 微服务架构：每个服务独立数据库，Flyway 随服务启动自动迁移，保证服务自治。
- CI/CD 流水线：与 Jenkins、GitLab CI、GitHub Actions 等工具集成，实现数据库变更的持续交付。
- 多环境部署：开发、测试、预发布、生产环境使用同一套脚本，消除环境漂移。
- 开源项目：贡献者无需手动执行建表脚本，运行项目时自动完成数据库初始化。
- 遗留系统现代化：通过 Baseline 功能将现有数据库纳入版本管理，逐步重构。
1.5 Flyway 核心工作流程
下图展示了 Flyway 从扫描脚本到执行迁移的完整工作流：
1.6 Flyway 架构组件
Flyway 的架构由四个核心组件构成，它们协同工作以实现数据库迁移的自动化管理：
注意：Flyway 不管理数据内容（DML），只管理数据库结构（DDL）和引用数据（如初始配置数据）。对于大量业务数据的迁移，建议使用 ETL 工具配合 Flyway 使用。