FlywayDB 是一款 开源数据库版本管理工具,开发中将表结构的变更或数据初始化脚本维护好,更新到测试环境或线上发版启动服务的时候,会检测版本号自动执行数据库变更,可以减少每次发版到其他环境的人工执行操作。
工作流程
-
初始化阶段
首次运行时检查目标数据库是否存在
flyway_schema_history
表,不存在则创建。 -
脚本扫描与版本比对
默认扫描
classpath:db/migration
目录下的脚本(可配置),按版本号排序后与历史表比对。
版本号规则 :V<版本号>__<描述>.sql
,版本号需唯一且递增,否则报错。版本号建议使用时间戳或递增数字,如V20230701__description.sql
-
迁移执行
对比历史表后,执行未应用的脚本,并记录版本、校验和等信息到元数据表。
使用 CRC32 算法校验脚本内容,防止篡改。
-
锁机制
通过数据库排他锁(如
SELECT ... FOR UPDATE
)协调多节点并发执行,确保迁移原子性。
项目集成
1. 添加依赖
xml
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>
2. Nacos配置
yaml
spring:
flyway:
enabled: true
locations: classpath:db/update
validate-on-migrate: true
encoding: UTF-8
# placeholders:
# table-prefix: "test_"
baseline-on-migrate: true # 对非空数据库首次使用时设为true
# baseline-version: "20250701" # 基线版本号
table: table_update_history # 使用自定义表名
out-of-order: false # 生产环境必须按顺序执行

这里以项目下3个脚本为例,先插入一张新表,然后分别插入1月到3月、4月到6月的数据,数据库中没有这张表。
项目启动完会看到库里多了event_tracking表,插入了两个脚本初始化的数据。
同时会按配置生成表变更记录,维护脚本变更版本号。
这里有几点要注意:
- 如果数据库用户没有建表权限,则需要管理员提前创建;
- 表结构需符合Flyway要求;
- 如果使用多个数据源,需要为每个数据源配置单独的Flyway实例,每个实例会维护自己的历史表;
- 可以配置clean-on-validation-error: true便于调试,但生产环境必须禁用此选项;
- 如果项目组开发人员比较多,有些迭代版本开发周期比较长,之前开发定义好的版本号,在开发环境执行没问题,等测完真正发版的时候,版本号可能不是最大的(中间有其他开发先发版),这时需要重新维护版本号;