SpringBoot整合Flyway实现数据库的初始化和版本管理

一、Flyway

1、介绍

Flyway 是一款开源的数据库版本管理工具。它可以很方便的在命令行中使用，或者在Java应用程序中引入，用于管理我们的数据库版本。

官方文档：https://flywaydb.org/documentation/

2、业务痛点

日常开发中常有以下场景：

• 一个系统有多套环境，更新表的SQL可能会遗漏某一个环境
• 每次部署一个新环境，就得把所有库表的创建SQL手动执行一遍。多希望服务启动，就创建自己需要的库表
• 每次发版要记录数据库变更信息，或者单独给出数据库升级脚本
• 别人需求新增了SQL你不知道，系统一跑出来个数据库报错又得问人或者排错
• …

3、个人理解

flyway，就像数据库界的Git。git做一个项目里代码的版本管理，flyway做一个项目数据库的版本管理。

• Version control for your database.

• Robust schema evolution across all your environments.

• With ease, pleasure and plain SQL.

使用了 Flyway 之后，如果再想进行数据库版本升级，就不用改之前的数据库脚本了，直接创建新的数据库脚本，项目在启动时检测了有新的更高版本的脚本，就会自动执行

二、SpringBoot整合flyway

1、整合

• 在pom文件中导入flyway依赖

<dependency>
  <groupId>org.flywaydbgroupId>
  <artifactId>flyway-coreartifactId>
  <version>5.2.4version>
dependency>

- 注意和springboot之间的版本适配问题
- flyway版本不建议太高

• 配置文件application或者bootstrap中新加flyway的配置

# flyway 配置
spring:
  flyway:
    # 启用或禁用 flyway
    enabled: true
    # flyway 的 clean 命令会删除指定 schema 下的所有 table, 生产务必禁掉。这个默认值是 false 理论上作为默认配置是不科学的。
    clean-disabled: true
    # SQL 脚本的目录,多个路径使用逗号分隔 默认值 classpath:db/migration
    locations: classpath:db/migration
    #  metadata 版本控制信息表 默认 flyway_schema_history
    table: flyway_schema_history
    # 如果没有 flyway_schema_history 这个 metadata 表， 在执行 flyway migrate 命令之前, 必须先执行 flyway baseline 命令
    # 设置为 true 后 flyway 将在需要 baseline 的时候, 自动执行一次 baseline。
    baseline-on-migrate: true
    # 指定 baseline 的版本号,默认值为 1, 低于该版本号的 SQL 文件, migrate 时会被忽略
    baseline-version: 1
    # 字符编码 默认 UTF-8
    encoding: UTF-8
    # 是否允许不按顺序迁移 开发建议 true  生产建议 false
    out-of-order: false
    # 需要 flyway 管控的 schema list,这里我们配置为flyway  缺省的话, 使用spring.datasource.url 配置的那个 schema,
    # 可以指定多个schema, 但仅会在第一个schema下建立 metadata 表, 也仅在第一个schema应用migration sql 脚本.
    # 但flyway Clean 命令会依次在这些schema下都执行一遍. 所以 确保生产 spring.flyway.clean-disabled 为 true
    schemas: flyway
    # 执行迁移时是否自动调用验证   当你的 版本不符合逻辑 比如 你先执行了 DML 而没有 对应的DDL 会抛出异常
    validate-on-migrate: true

注意clean-disabled！！！

- 表示是否要清除已有库下的表
- 即执行脚本V1__xxx.sql，会先清除已有库下的表！！然后再执行脚本
- 设置为true，即确定关掉clean功能

• resource/db/migration下添加数据库脚本（这个路径是上面配置中写的）

• 启动服务，显示控制台可以看到SQL被执行，并产生了历史记录表

2、SQL文件命名

注意SQL的命名规范有要求：

举例：V2.0.1.7__create_core_table.sql

• V是前缀 表示这个文件只会被执行一次

• 2.0.1.7为版本号 ，高版本的执行后不会再执行低版本的SQL。如2.0.1.7先执行了，2.0.1.6就不会被执行了

• __ ： 两个下划线表示分隔符

• create_user_table :脚本功能表述

• .sql: 后缀

注意flyway比较版本的先后是采用左对齐原则, 缺位用 0 代替，比如

- 1.0.1.1 比 1.0.1 高
- 1.0.10.0 比 1.0.9.9 高
- 1.0.10 和 1.0.010 一样高

需要执行多次的，以大写"R"开头，命名如R__insertInfo.sql ，R的脚本只要改变了就会执行,R不带版本号。

3、版本号校验算法

flyway在升级数据库时会先计算之前已经升级过的脚本的checksum值和数据库的checkSum值进行比对，如果老脚本发生了变化后checkSum校验就会失败，从而抛出异常，checkSum计算算法为CRC32 (循环冗余校验码)算法

新增的脚本则会和数据库中的版本号进行比较，如果小于数据库存储的最后一个版本号，也不会继续执行。

4、工作流程

• 项目启动，成功连接到数据库，flyway开始运行。
• 第一次使用，flyway会创建flyway_schema_history表，用于记录SQL的执行记录
• flyway扫描classpath:db/migration路径下的所有SQL脚本，并与flyway_schema_history表的记录对比

- 若表里没记录，即新SQL，执行并将信息写入history表
- R开头的文件只要发生修改，都会执行一遍
- V开头的文件，如果上次执行过后又发生了修改，则服务启动报错
- 想让V开头的已经执行过的文件再执行一次，就得清楚history表中的数据后再启动服务

• 根据表中的sql记录最大版本号，忽略版本号不高于它的SQL脚本

5、注意事项

• 报错后需要删除flyway_schema_history中记录，否则启动失败
• V文件的优先级高于R，假如三个V迁移脚本和一个R(无论新建还是修改)一起执行，其中一个V报错，则V会全部执行完成且记录到flyway_schema_history中，而R不执行且不记录，删除表中报错记录后，重新启动，则执行原错误V和未执行的R
• 多个要执行的R中，如果出现了其中一个出现了错误，则在其后的R都不执行
• R的执行顺序根据命名来进行排序
• 一个文件中ddl并不由一个事务管理，比如创建三个表，中间创建表语句报错，则第一个表还是会创建成功并且提交事务
• 同一个迁移文件下假设都是DML（即insert、delete、update），那么如果中间出现错误，所有的DML语句都会回滚
• 已经执行过的迁移文件(V)不能修改，否则启动报错
• 版本号相同会报错（Found more than one migration with version 1.0.0.9）
• 删除sql文件后启动会报错，报错如下：

If you removed this migration intentionally, run repair to mark the migration as
deleted.