Spring Boot 2 实战：使用 Flyway 管理你数据库的版本变更

1. 前言

随着项目的不断迭代，数据库表结构、数据都在发生着变化。甚至有的业务在多环境版本并行运行。数据为王的时代，管理好数据库的版本也成为了迫切的需要。如何能做到像 Git 之类的版本控制工具来管理数据库？Java 项目中常用 Flyway 和 Liquibase 来管理数据库版本。其中 Flyway 相对来说比较受欢迎。

2. Flyway 的特点

Flyway 大受欢迎是因为它具有以下优点：

• 简单 非常容易安装和学习，同时迁移的方式也很容易被开发者接受。
• 专一 Flyway 专注于搞数据库迁移、版本控制而并没有其它副作用。
• 强大 专为连续交付而设计。让Flyway在应用程序启动时迁移数据库。

3. Flyway 的工作机制

Flyway 需要在 DB 中先创建一个 metadata 表 (缺省表名为 flyway_schema_history), 在该表中保存着每次 migration （迁移）的记录, 记录包含 migration 脚本的版本号和 SQL 脚本的 checksum 值。下图表示了多个数据库版本。

对应的 metadata 表记录：

Flyway 扫描文件系统或应用程序的类路径读取 DDL 和 DML 以进行迁移。根据metadata 表进行检查迁移。如果脚本声明的版本号小于或等于标记为当前版本的版本号之一，将忽略它们。其余迁移是待处理迁移：可用，但未应用。后按版本号对它们进行排序并按顺序执行 并将执行结果写入 metadata 表。

对应的 metadata 表记录：

Flyway 支持命令行（需要下载命令行工具）和 Java Api ，也支持构建工具 Maven 和 Gradle 。这里我们将目光放在 Java Api 上。

3. Flyway 的规则

Flyway 是如何比较两个 SQL 文件的先后顺序呢？它采用 采用左对齐原则, 缺位用 0 代替 。举几个例子：

1.0.1.1 比 1.0.1 版本高。
1.0.10 比 1.0.9.4 版本高。
1.0.10 和 1.0.010 版本号一样高, 每个版本号部分的前导 0 会被忽略。

Flyway 将 SQL 文件分为 Versioned 、Repeatable 和 Undo 三种：

• Versioned 用于版本升级, 每个版本有的版本号并只能执行一次.
• Repeatable 可重复执行, 当 Flyway检测到 Repeatable 类型的 SQL 脚本的 checksum 有变动, Flyway 就会重新应用该脚本. 它并不用于版本更新, 这类的 migration 总是在 Versioned 执行之后才被执行。
• Undo 用于撤销具有相同版本的版本化迁移带来的影响。但是该回滚过于粗暴，过于机械化，一般不推荐使用。一般建议使用 Versioned 模式来解决。

这三种的命名规则如下图：

• Prefix 可配置，前缀标识，默认值 V 表示 Versioned, R 表示 Repeatable, U 表示 Undo
• Version 标识版本号, 由一个或多个数字构成, 数字之间的分隔符可用点 . 或下划线 _
• Separator 可配置, 用于分隔版本标识与描述信息, 默认为两个下划线 __
• Description 描述信息, 文字之间可以用下划线 _ 或空格 分隔
• Suffix 可配置, 后续标识, 默认为 .sql

4. Spring Boot 集成 Flyway

Spring Boot 提供了对 Flyway 的自动配置 。使我们可以开箱即用 Flyway 进行数据库版本控制。

4.1 Flyway 依赖

你只需要引入依赖：

<!-- 无需版本号 -->
 <dependency>
      <groupId>org.flywaydb</groupId>
      <artifactId>flyway-core</artifactId>
 </dependency>