本文转载自微信公众号《Java极客技术》，作者鸭血范。转载本文请联系Java极客技术公众号。大家好，我是阿芬。不知道大家有没有遇到过这样的场景。一套代码部署在不同的环境中。随着时间的推移，每个环境中的代码都有不同的版本。版本控制，但往往很容易忘记在数据库层面进行更新！前言比如一开始环境A和环境B的代码版本是一样的，但是随着版本的迭代，环境A的系统一直在不断迭代，但是环境B的系统由于各种原因没有升级，一直保持原来的版本。如果某个时候需要升级环境B的系统，你会发现中间出现了很多版本，每个版本之间的差距非常大，数据库结构已经调整，无法打包发布直接地。调整后的SQL必须在环境B执行一次，这时候如果SQL版本做得好，问题不大，顺序执行即可，但如果中间有人遗留或遗漏记录，就可以只有比较数据库结构才能解决。数据迁移我们前面提到的场景的专业术语叫做数据迁移，那么为什么会有数据迁移场景呢？我从官网上截了图，大家可以看看。虽然可能和我实际开发的不太一样，但是和这种场景差不多，有多个环境。可见虽然我们的代码可以通过版本迭代来控制，但是我们的数据库却不行。很多时候，我们甚至会忘记脚本是否已经执行。这种事情，光靠人是很难记住的。FlywayFlyway就是这样一个用来解决数据库迁移的工具。连接Flyway后，会在数据库中生成一个名为flyway_schema_history的默认数据表，用来跟踪数据库的变化。程序启动时，Flyway会在文件系统或类路径下寻找迁移脚本。每个迁移步骤都有相应的命名规则。Flyway会根据文件的版本号进行迁移。每次迁移后，都会在flyway_schema_history表中插入一条类似如下的记录，记录该记录版本对应的脚本文件和校验信息。:每次启动只会执行版本最高的脚本，如果版本没变，改了脚本就不会启动。Flyway的迁移类型最常见的版本迁移类型是版本化迁移。每个迁移都会对应一个迁移版本。迁移后的版本必须是全局唯一的。版本迁移最大的特点就是只按顺序执行。撤消迁移每一次撤消迁移对应一个版本迁移，也就是说版本迁移存在撤消迁移，每一次撤消迁移和版本迁移是一一对应的，对应的版本号必须一致。RepeatableMigrationRepeatableMigration有描述和验证码，但是没有版本号。每次启动程序，如果脚本文件有变化，就会执行。基于SQL的迁移上述类型都是基于SQL文件执行的，但是每种类型的命名格式不同。下图截自官网。让我们来看看每种类型的文件。按照下面的格式来命令，其中分隔符是两个下划线。主要分为以下几个部分：prefix：前缀，不同的类型使用不同的前缀，版本迁移使用V，undo迁移使用U，可重复迁移使用R，当然这些都是可以配置的；version：版本号，可以使用点符号或单下划线链接；Separator：分隔符，两个下划线，也可配置；描述：版本描述可以用下划线和空格分隔；Suffix：后缀，一般是.sqlSpringBoot项目接入FlywaySpringBoot项目接入Flyway很简单，主要分为以下几个步骤，我们依次来看一下。添加依赖
