4. Flyway入门:工作原理、安装配置与命令行操作

Flyway 是目前最流行的开源数据库迁移工具之一,采用“约定优于配置”的设计哲学,通过版本化的 SQL 脚本实现对数据库 schema 的增量变更管理。本节将系统讲解 Flyway 的核心工作原理、安装配置方法以及最常用的四个命令行操作:migrate、info、validate 和 baseline。

4.1 Flyway 工作原理

Flyway 的核心机制是在目标数据库中维护一张元数据表(默认名为 flyway_schema_history),用于记录所有已执行的迁移脚本及其校验和。每次执行迁移时,Flyway 会扫描指定路径下的迁移脚本,与元数据表中的记录进行比对,只执行尚未运行过的脚本,并保证每个脚本只执行一次且顺序严格递增。

Flyway 迁移执行流程 1. 扫描迁移脚本 2. 比对元数据表 3. 校验脚本完整性 4. 执行未迁移脚本 5. 写入迁移记录 关键说明: • 迁移脚本命名格式:V{版本号}__{描述}.sql(如 V1.0.1__create_user_table.sql) • 元数据表记录:版本号、脚本名称、校验和(checksum)、执行时间、成功状态 • 校验失败时 Flyway 会阻止迁移,确保数据库状态与脚本一致

4.2 Flyway 的安装与配置

4.2.1 安装方式

Flyway 提供多种安装方式,适用于不同开发环境。以下为三种主流安装方式:

安装方式 适用场景 命令/步骤
命令行(CLI) 本地开发、CI/CD 节点 下载 tar.gz/zip 包,解压后配置 PATH
Maven 插件 Java 项目构建集成 在 pom.xml 中添加 flyway-maven-plugin
Gradle 插件 Gradle 项目构建集成 在 build.gradle 中应用 org.flywaydb.flyway 插件
Docker 镜像 容器化 CI/CD 流水线 docker pull flyway/flyway

4.2.2 配置文件(flyway.conf)

Flyway 通过 flyway.conf 文件集中管理数据库连接与行为参数。以下为典型配置示例:

# flyway.conf
flyway.url=jdbc:postgresql://localhost:5432/mydb
flyway.user=db_user
flyway.password=db_password
flyway.locations=filesystem:./sql/migrations
flyway.schemas=public
flyway.baselineOnMigrate=true
flyway.encoding=UTF-8
flyway.placeholderReplacement=true
flyway.placeholders.env=dev
配置要点:
  • flyway.locations:指定迁移脚本存放路径,支持 filesystem: 和 classpath: 前缀。
  • flyway.baselineOnMigrate:当数据库已有表结构但无元数据表时,自动执行 baseline 操作。
  • flyway.placeholders:支持在 SQL 脚本中使用 ${placeholder} 占位符,实现环境差异化。

4.3 Flyway 命令行基本操作

Flyway CLI 提供多个核心命令,用于管理数据库迁移全生命周期。以下为最常用的四个命令:

4.3.1 migrate —— 执行迁移

migrate 是 Flyway 最核心的命令,它会扫描所有未执行的迁移脚本,按版本号顺序依次执行,并将执行记录写入元数据表。

# 执行所有待迁移脚本
flyway migrate

# 指定目标版本(仅执行到 V2.0 为止)
flyway migrate -target=2.0

# 指定配置文件
flyway migrate -configFiles=./config/flyway.conf

4.3.2 info —— 查看迁移状态

info 命令用于查看当前数据库的迁移状态,包括已执行和待执行的脚本列表。输出结果以表格形式呈现,便于快速了解数据库版本演进情况。

flyway info

执行结果示例:

Category Version Description Type Installed On State
Versioned 1.0 Create user table SQL 2025-03-10 09:15:22 Success
Versioned 1.1 Add email column SQL 2025-03-11 14:30:05 Success
Versioned 2.0 Create order table SQL — Pending

4.3.3 validate —— 校验迁移脚本

validate 命令用于校验已执行的迁移脚本是否被篡改。Flyway 会重新计算每个已执行脚本的 checksum,与元数据表中的记录进行比对。如果发现不一致,则抛出异常,防止数据库状态与脚本不一致。

# 校验所有已执行脚本的完整性
flyway validate

# 校验并忽略迁移失败记录
flyway validate -ignoreMigrationPatterns=*:failed
重要提示:在生产环境中,建议将 validate 作为 CI/CD 流水线中 migrate 的前置步骤。如果校验失败,应中止流水线并人工介入排查脚本变更原因,避免因脚本篡改导致数据库状态不可控。

4.3.4 baseline —— 基线化

baseline 命令用于将现有数据库标记为某个版本,使 Flyway 能够从该版本开始管理后续迁移。这在以下场景中尤为关键:

  • 现有数据库引入 Flyway:数据库已有表结构,但未使用 Flyway 管理。通过 baseline 将当前状态标记为基线版本,后续迁移脚本从基线版本之后开始执行。
  • 跳过已有脚本:当迁移脚本已在其他环境执行过,但当前数据库的元数据表缺失时,使用 baseline 跳过已执行脚本。
# 将当前数据库标记为版本 1.0
flyway baseline -baselineVersion=1.0 -baselineDescription="Initial baseline"

# 使用配置文件中的 baseline 设置
flyway baseline
Baseline 前后对比 Baseline 前 • 数据库已有表结构 • 无 flyway_schema_history 表 • Flyway 无法识别当前版本 • 直接 migrate 会尝试执行所有脚本 • 可能导致重复创建表而失败 Baseline 后 • 创建 flyway_schema_history 表 • 插入基线版本记录(如 V1.0) • Flyway 识别当前版本为基线版本 • 后续 migrate 只执行 > V1.0 的脚本 • 现有表结构不受影响 baseline

4.4 命令操作对比总结

命令 核心作用 执行频率 CI/CD 集成建议
migrate 执行待迁移脚本,更新数据库 schema 每次部署 作为部署流水线的核心步骤
info 查看迁移历史与当前状态 按需查询 用于流水线日志输出和状态报告
validate 校验已执行脚本的完整性 每次迁移前 作为 migrate 的前置检查步骤
baseline 初始化现有数据库的基线版本 首次接入时 用于新环境初始化或数据库重建
实践要点:
  • 在 CI/CD 流水线中,建议按 validate → migrate → info 的顺序执行命令,确保迁移安全可控。
  • 对于已有生产数据的数据库,首次引入 Flyway 时必须先执行 baseline,再执行 migrate。
  • 迁移脚本一旦提交并执行,禁止修改已发布的脚本内容。如需变更,应创建新的版本脚本。