对于数据库迁移工具，网上开源的不少，我选择大家较为常用的flyway。它可以帮助我们在各个环境中同步数据库表结构，尤其在协同开发的过程中flyway更像git一样，对成员的数据库修改进行版本管理和执行。
对于flyway的介绍和基础使用已经有不少的教程，本文不做赘述，这里想为读者理清楚初学者容易犯迷糊的几个概念：
- 已有项目如何引入flyway
- flyway的checksum是在做什么
- flyway是否可以从数据库的创建开始迁移
已有项目如何引入flyway
对于一个新起的项目，引入flyway可参考网上80%的新手教程。然而对于一个已有项目，这里所说的已有项目，指的是数据库中已经存在了table和数据，这时候我们希望把这些create、alter……操作管理起来，从而引入flyway。
FlywayCallback not present.png
POM.xml如下所示：
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>5.2.4</version>
</dependency>
这个依赖是为了保证我们Springboot项目可以在启动后自动进行数据库迁移等操作，但为了使用方便，我们也可以引入maven操作，通过maven-cli手动进行迁移，以方便我们开发和调试，操作方式为：在POM.xml中加入一个flyway plugin，这里的dbuser、dbpwd一系列参数可在<properties></properties>中提前定义作为变量传入：
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.2.4</version>
<configuration>
<user>${dbuser}</user>
<password>${dbpwd}</password>
<driver>com.mysql.cj.jdbc.Driver</driver>
<url>jdbc:mysql://${dbhost}:${dbport}/${dbname}?characterEncoding=utf8</url>
<table>flyway_schema_history</table>
</configuration>
</plugin>
接下来我们激活flyway，仅需要配置项进行配置即可：
#application.properties
spring.flyway.clean-disabled=true
spring.flyway.enabled=true
spring.flyway.encoding=UTF-8
spring.flyway.locations=classpath:db/migration
spring.flyway.table=flyway_schema_history
spring.flyway.baseline-on-migrate=true
spring.flyway.baseline-version=20190923105701
spring.flyway.clean-disabled=true：首先需要强调一点，在生产环境上必须关闭flyway:clean指令，因为一旦误操作，所有数据将会被清空；
spring.flyway.enable=true：打开flyway，使得每次程序启动的时候都会尝试去迁移数据。这当然是好的，可以避免因为数据库变动导致项目运行失败；
spring.flyway.locations=classpath:db/migration：我们需要将指定项目中需要迁移的sql文件在哪个位置，在springboot项目中classpath指的是resource文件夹；
spring.flyway.table=flyway_schema_history：当flyway第一次运行时，会在我们对应的数据库中新建一个记录脚本运行情况的table，如果不设置，默认就是flyway_schema_history，当然也可以定义其他名字；
spring.flyway.baseline-on-migrate=true：对于已经存在的项目，数据库中存在数据，这个时候我们需要通过设置baseline告诉flyway，这个baseline及之前的sql脚本都不要执行了（否则会报重复的错误）；
spring.flyway.baseline-version=20190923105701：配合上一条配置，告诉系统具体baseline版本号，包括这条版本号在内的之前所有sql脚本，都不会在迁移时执行。
flyway的checksum是在做什么
我们先认识一下flyway_schema_history：
flyway_schema_history
官网已经说的很清楚，flyway获取flyway_schema_history中最新成功记录的版本号（基准version），与项目中db/migration文件夹中的文件version进行比对，当version大于基准version则执行。既然通过版本号就可以完成迁移前判断，那还需要checksum做什么呢？
其实我们在使用flyway的时候，需要养成这样一个习惯，一旦执行过的sql脚本就不要去修改，如果需要对已有数据表进行增删改的操作，应该新建一个脚本执行。但是对于修改已经执行过的sql脚本，flyway也有预防，那就是checksum。每个sql脚本在执行前会将基本信息写入flyway_schema_history中，flyway会把每个脚本作为输入，通过某算法（不清楚）输出一个整数，这个数就是checksum，flyway在工作之前，会先基于baseline逐个脚本比对其数据库中的checksum值，如果计算结果不同，则会报mismatch的错误。我们做这样一个实验就很清晰：
create table school_date_configuration
(
id integer not null auto_increment unique,
date DATE not null, //去掉not null
weekday integer,
school_id integer,
create_time DATETIME not null default current_timestamp,
update_time DATETIME default current_timestamp on update current_timestamp
);
这个sql脚本已经通过flyway执行，且记录在flyway_schema_history中：
修改前
当我们去掉date 字段的not null之后再次运行flyway，会出现mismatch报错：
修改后
可以想见，flyway在比对版本号之前，会先逐一比对checksum，以保证之前执行过的文件没有被修改过。这个问题也容易解决，在命令行运行：
mvn flyway:repair
flyway会单独执行修改过的脚本，让它在数据库中生效。
flyway是否可以从数据库的创建开始迁移
就目前我的了解来看，flyway是在已有数据库的基础上，对指定数据库进行数据迁移，大家注意到，flyway的配置中需要指定数据库的相关信息（在springboot集成时，它不需要配置，是因为springboot本身会与数据库进行配置，从而将配置告诉flyway）。所以如果希望自动创建数据库，一个方式是通过java进行创建，另一种是通过容器部署项目，在容器启动之处就通过命令行脚本初始化数据库。
网友评论