Flyway 是一个开源的数据库迁移工具，专为管理数据库结构变更而设计，广泛应用于 Java 生态系统中，尤其与 Spring Boot、Maven、Gradle 等框架深度集成。
✅ 核心功能
- 版本化迁移 ：通过命名规范的 SQL 脚本（如
V1__Create_user_table.sql）或 Java 类（实现JdbcMigration）记录数据库变更。 - 自动执行：应用启动时自动检测并按版本顺序执行未应用的迁移脚本，确保数据库始终与代码版本一致。
- 校验与修复 ：支持校验脚本完整性，防止被篡改；提供
repair命令修复损坏的元数据表。 - 多数据库支持：兼容 MySQL、PostgreSQL、Oracle、SQL Server、H2 等主流关系型数据库。
📂 迁移脚本命名规范
表格
| 类型 | 命名格式 | 说明 |
|---|---|---|
| SQL 迁移 | V<版本>__<描述>.sql |
如 V1__create_table.sql |
| 可重复迁移 | R__<描述>.sql |
每次启动都会重新执行，用于视图、函数等 |
| Java 迁移 | 实现 JdbcMigration 接口 |
适用于复杂逻辑，如数据迁移、条件判断 |
🔄 工作流程
- 应用启动时，Flyway 检查数据库中的
flyway_schema_history表。 - 对比该表记录与项目中所有迁移脚本的版本。
- 按版本号升序执行缺失的迁移脚本。
- 更新元数据表，记录执行时间、状态、校验和等信息。
💡 典型应用场景
- CI/CD 流水线：确保测试、预发、生产环境数据库结构完全一致。
- 团队协作：避免开发人员手动执行 DDL 导致的环境差异。
- 微服务架构：每个服务独立管理自己的数据库迁移，解耦性强。
🛠️ 配置示例（Spring Boot）
<!-- flywaydb数据库维护，迁移工具 -->
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>✅ 优势对比（vs. 手动脚本）
表格
| 特性 | Flyway | 手动执行 |
|---|---|---|
| 自动化 | ✅ 是 | ❌ 否 |
| 版本控制 | ✅ 是 | ❌ 否 |
| 回滚支持 | ⚠️ 有限（需手动） | ✅ 可自定义 |
| 多环境支持 | ✅ 是 | ⚠️ 易出错 |
| 集成度 | ✅ 深度集成 Java 生态 | ❌ 无 |
⚠️ 当前存在的问题
- 不支持原生回滚：需手动编写回滚脚本或依赖第三方工具（如 Liquibase）。
- 脚本耦合性强：迁移脚本与业务逻辑绑定，修改历史脚本可能导致部署失败。
- 复杂事务处理困难：跨多个数据库或分布式事务场景下需额外设计。
Flyway 通过标准化、自动化的方式，显著降低了数据库变更的风险与运维成本，是现代 Java 应用不可或缺的 DevOps 工具之一。
springboot2.x集成Flyway
如果数据库表为空：
1.引入
<!-- flywaydb数据库维护，迁移工具 -->
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>2.在你的项目中创建以下目录和文件：
src/main/resources/
└── db/
└── migration/
└── V1__init_schema.sql3.写入创建表或者初始数据的sql
注：
如果有表数据，引入Flyway 是为了修改数据信息或者新增表结构
✅ 方式一：**推荐！使用 baselineOnMigrate=true（最安全的生产兼容方案）**
如果你的数据库中已有表结构，且这些表是你希望 Flyway **接管并视为"版本 1"** 的起点，最推荐的做法是：
application.yml 中：
spring:
flyway:
baseline-on-migrate: true
baseline-version: 1将V1__add_index.sql改为V2__add_index.sql
✅ 作用 ：Flyway 会自动创建
flyway_schema_history表，并将当前数据库状态标记为版本1，之后所有新的迁移脚本（如V2__add_index.sql）将从版本 2 开始正常执行。💡 这是生产环境最常用、最安全的方案，无需删除数据，无需手动干预数据库。