SpringBoot集成Flyway

在项目或产品中，很难一开始就把业务理清楚，把数据库表设计好，因此数据表也会在迭代周期不断迭代。在Java应用程序中使用Flyway，能快速有效地用于迭代数据库表结构，并保证部署到测试环境或生产环境时，数据表都是保持一致的。

为什么要使用Flyway?

在多人开发项目中，我们一般都使用Git或者SVN对代码进行版本控制，主要就是解决多人开发代码冲突和版本回退问题。
数据库的变更也需要版本控制，在日常开发中，我们经常会遇到下面的问题：

1、自己在本地写的SQL忘记在测试或生产环境执行。
2、别人写的SQL我们不知道是否在其他环境执行过。
3、需要新增环境做数据迁移
4、每次发送版本都需要手动执行一些SQL。

Flyway是如何工作的?

流程如下：

1、项目启动，程序会完成数据库连接池的建立，Flyway自动运行。
2、初次使用Flyway，它会自动创建一个 flyway_schema_history 表，用于记录SQL执行记录。
3、Flyway会扫描yml下面配置的所有SQL脚本，与 flyway_schema_history 表进行版本号对比。
4、校验通过，则会根据SQL记录最大的版本号，忽略所有版本号不大于该版本的脚本。再按照版本号从小到大，逐个执行其余脚本。

代码集成

引入依赖

这里我的SpringBoot的版本是 2.2.x，如果你的版本不是2.X的百度一下找一下自己适配的版本。

<!-- 整合flywaydb -->
<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>6.1.0</version>
</dependency>

Yml配置

spring:
  # 数据源配置
  flyway:
    # 是否启用flyway
    enabled: true
    # 编码格式，默认UTF-8
    encoding: UTF-8
    # 迁移sql脚本文件存放路径，默认db/migration
    locations: classpath:db/migration
    # 迁移sql脚本文件名称的前缀，默认V
    sql-migration-prefix: V
    # 迁移sql脚本文件名称的分隔符，默认2个下划线__
    sql-migration-separator: __
    # 迁移sql脚本文件名称的后缀
    sql-migration-suffixes: .sql
    # 迁移时是否进行校验，默认true
    validate-on-migrate: true
    # 当迁移发现数据库非空且存在没有元数据的表时，自动执行基准迁移，新建schema_version表
    baseline-on-migrate: true
    # flyway 的 clean 命令会删除指定 schema 下的所有 table, 生产务必禁掉。
    clean-disabled: true
    #  metadata 版本控制信息表 默认 flyway_schema_history
    table: flyway_schema_history
    # 指定 baseline 的版本号,默认值为 1, 低于该版本号的 SQL 文件, migrate 时会被忽略
    baseline-version: 1

创建SQL脚本

我们在项目的 resource目录下建立 db/migration。

命名规则主要有两种：

规则： 前缀+版本+分隔符+描述+文件后缀

前缀V：如果这个SQL只运行一次，则以大写字母 V 开头, V+版本号(版本号的数字以 . 或 “_” 分割)
如：V1.1add_account_sql、V1_1add_account_sql

前缀R：如果这个SQL可重复运行，则以大写字母 R 开头。

注意这个不需要版本号！

如：R__truncate_user_dml.sql

版本号：任意的数字版本均可，可以是一个完整的数字或者用点符号分割的数字，版本之间从左到右进行比较大小，遇到点符号进行分割，以0开头的数字会自动移除前面的0后比较大小。

分割符：默认是两个下划线作为分隔符，分割版本和描述。

描述：官方文档上说明是：下划线或者空格分割单词即可。实际短横线分割单词也可以，理论上只要不和分割符冲突即可。

测试

需要注意的几个点：

1、V开头的SQL执行优先级要比R开头的SQL优先级高。
2、如果修改图片上面 V1.1__add_user.sql 里面的内容就会报错，因为这个脚本只能被执行一次，除非升级版本号

3、V开头的脚本版本号后面需要两个下划线隔开，这个可以在yml自定义配置

其他配置

flyway.baseline-description对执行迁移时基准版本的描述.
flyway.baseline-on-migrate当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.
flyway.baseline-version开始执行基准迁移时对现有的schema的版本打标签，默认值为1.
flyway.check-location检查迁移脚本的位置是否存在，默认false.
flyway.clean-on-validation-error当发现校验错误时是否自动调用clean，默认false.
flyway.enabled是否开启flywary，默认true.
flyway.encoding设置迁移时的编码，默认UTF-8.
flyway.ignore-failed-future-migration当读取元数据表时是否忽略错误的迁移，默认false.
flyway.init-sqls当初始化好连接时要执行的SQL.
flyway.locations迁移脚本的位置，默认db/migration.
flyway.out-of-order是否允许无序的迁移，默认false.
flyway.password目标数据库的密码.
flyway.placeholder-prefix设置每个placeholder的前缀，默认${.
flyway.placeholder-replacementplaceholders是否要被替换，默认true.
flyway.placeholder-suffix设置每个placeholder的后缀，默认}.
flyway.placeholders.[placeholder name]设置placeholder的value
flyway.schemas设定需要flywary迁移的schema，大小写敏感，默认为连接默认的schema.
flyway.sql-migration-prefix迁移文件的前缀，默认为V.
flyway.sql-migration-separator迁移脚本的文件名分隔符，默认__
flyway.sql-migration-suffix迁移脚本的后缀，默认为.sql
flyway.tableflyway使用的元数据表名，默认为schema_version
flyway.target迁移时使用的目标版本，默认为latest version
flyway.url迁移时使用的JDBC URL，如果没有指定的话，将使用配置的主数据源
flyway.user迁移数据库的用户名
flyway.validate-on-migrate迁移时是否校验，默认为true

可能会遇到的错误

错误一：

SELECT command denied to user 'test'@'xxxxx' for table 'user_variables_by_thread'

解决方法一：开权限

从报错信息看，就是test用户对user_variables_by_thread表没有select权限导致。

最直接的解决方法就是给对应用户设置权限即可。

解决方法二：修改Flyway版本

修改为 5.2.1版本以下的版本。

如果您在集成过程中有遇到其他错误可以反馈以下，我记录下。

打赏