写在前面
最近由于项目变更比较大，需要经常修改表结构，然后对应的测试，开发，生产环境数据库均要修改，有时候一不小心就忘记修改某个环境下的数据库了，
等出问题才发现表结构没有更新，如果项目还没上线，还可以把表删除了重新创建，但是如果项目已经上线了，就不能这样简单粗暴了，我们需要通过 SQL 脚本
在已有数据表的基础上进行升级。鉴于这种情况，于是决定寻找数据库版本控制工具。
在Java这部分，对数据库版本控制的主要有两个工具：
- Flyway
- Liquibase
两个工具各有千秋，但是核心功能都是数据库的版本管理，这里主要来看 Flyway。就像我们使用 Git 来管理代码版本一样，Flyway 可以用来管理数据库版本。
Flyway官网地址：https://flywaydb.org
1、Flyway是如何工作的
关于FlyWay工作原理，官网给出了具体的工作原理图。官网原理图地址：https://flywaydb.org/getstarted/how
这里简单记录一下，仅做备忘。
1.1 场景一：使用Flyway从无到有创建数据库
Flyway用'schema_version_history'数据表存放数据库schema的历史记录，跟踪数据库结构的变更；
由于刚开始数据库为空，Flyway找不到schema_version_history数据表，所以Flyway找不到它，就在数据库中创建了此表，
之后我们则需要在项目中定义Migration，通常用SQL或Java定义。
如下图所示，Flyway在运行时会顺序执行上图中的Migration1和Migration 2来实现对数据库的更新；同时'schema_version_history'表也会记录下这两次修改。
'schema_version_history'表记录修改历史。如下图所示：
说明：
脚本文件名(对应flyway_schema_history表的script字段)定义规则：
常用格式如下：
$PREFIX$VERSION__$REMARK.$SUBFIX
说明：
$prefix 表示 前缀，可在配置中指定，默认为 V；
$version 表示 版本号，版本号中也可以使用 . 或 _分隔，在解析时会将 _ 转换为 . 再保存到flyway_schema_history表的version字段中;
$remark 表示 备注，解析后会将这部分写入到描述字段中;
$subfix 表示 后缀，可在配置中指定，默认为 .sql ;
版本号与备注之前使用__分隔;
例如： V20200307_01__initial.sql
1.2 场景二：基于已有数据库更新
在此场景下，Flyway仍然会遍历项目中定义的各个Migration，并参照schema_version_history数据表，忽略版本号低于或等于当前版本的Migration，
剩下的就是Pending Migration(待处理迁移版本)，然后按照版本号顺序执行Pending Migration，如下图所示：
'schema_version_history'表记录修改历史。如下图所示：
因此，每当我们要对数据库的DDL或者DML进行迁移时，就只需要定义一个更高版本的Migration。
2、Spring Boot整合 Flyway
这部分也可以参考官网使用指导，官网整合地址：https://flywaydb.org/documentation/plugins/springboot
2.1 整合步骤
2.1.1 在项目的pom文件中导入Flyway依赖，目前官网最新版本如下：
<dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>6.3.0</version> </dependency>
2.1.2 在application.properties或者application.yml文件添加配置
# 说明，在spring boot 1.x中，属性前缀为flyway，在spring boot 2.x中为spring.flyway，这里需要区分不同版本 Spring.flyway: # 到新的环境中数据库中有数据，且没有flyway_schema_history表时，是否执行迁移操作。
如果设置为false，在启动时会报错，并停止迁移;
如果设置为true,则生成history表并完成所有的迁移，要根据实际情况设置; baseline-on-migrate: false # 执行时标记的tag 默认为<<Flyway Baseline>> baseline-description: <<Flyway Baseline>> # 是否启用flyway enabled: true # 检测迁移脚本的路径是否存在，如不存在，则抛出异常 check-location: true # 脚本位置 locations: classpath:db/migration # 在迁移时，是否校验脚本，假设V1.0__初始.sql已经迁移过了，在下次启动时会校验该脚本是否有变更过，则抛出异常 validate-on-migrate: true 特别说明： 如果非空数据库迁移，在目标数据库中手动建flyway_schema_history表并手动写入初始化的脚本记录,
使flyway跳过最初的校验即可，后续可以保证版本的统一;
2.1.3 创建迁移数据库脚本文件
可以在项目模块下的 resources 目录下，手动创建 db/migration 目录，然后在该目录下创建数据库脚本，数据库脚本的命名方式可以参考上面的说明：
“脚本文件名(对应flyway_schema_history表的script字段)定义规则”，当然也可以看下面：
脚本文件名(对应flyway_schema_history表的script字段)定义规则：
常用格式如下：
$PREFIX$VERSION__$REMARK.$SUBFIX
说明：
$prefix 表示 前缀，可在配置中指定，默认为 V；
$version 表示 版本号，版本号中也可以使用 . 或 _分隔，在解析时会将 _ 转换为 . 再保存到flyway_schema_history表的version字段中;
$remark 表示 备注，解析后会将这部分写入到描述字段中;
$subfix 表示 后缀，可在配置中指定，默认为 .sql ;
版本号与备注之前使用__分隔;
例如： V20200307_01__initial.sql
完成这些之后，在数据库中创建一个空的目标数据库，然后启动项目进行验证。
2.1.4 验证
项目启动有如下日志信息，表明校验成功：
补充：
如果是在一个全新的项目中使用 Flyway，那么在新建一个 Spring Boot 项目时，就有 Flyway 的选项，只需要勾选即可，如下图所示：
项目创建成功后，resources 目录下也会多出来一个 db/migration 目录，这个目录用来存放数据库脚本，如下图所示：
