大家在平时开发自己写SQL语句忘记在所有环境执行，需要新增环境做数据迁移，那么遇到这样的问题该如何解决呢？本文通过场景分析给大家介绍java 自动升级SQL脚本的策略，感兴趣的朋友一起看看吧
为什么要用Flyway
在日常开发中，我们经常会遇到下面的问题：
- 自己写的SQL忘了在所有环境执行；
- 别人写的SQL我们不能确定是否都在所有环境执行过了；
- 有人修改了已经执行过的SQL，期望再次执行；
- 需要新增环境做数据迁移；
- 每次发版需要手动控制先发DB版本，再发布应用版本;
其它场景...
由于项目需求的变化，或者前期设计缺陷，导致在后期需要修改数据库，这应该是一个比较常见的事情，如果项目还没上线，你可能把表删除了重新创建，但是如果项目已经上线了，就不能这样简单粗暴了，每次运维部署项目，还得手动执行一遍SQL文件。我们需要通过 SQL 脚本在已有数据表的基础上进行升级。
有了flyway，这些问题都能得到很好的解决。
使用了 Flyway 之后，如果再想进行数据库版本升级，就不用该以前的数据库脚本了，直接创建新的数据库脚本，项目在启动时检测了有新的更高版本的脚本，就会自动执行，这样，在和其他同事配合工作时，也会方便很多。因为正常我们都是从 Git 上拉代码下来，不拉数据库脚本，这样要是有人更新了数据库，其他同事不一定能够收到最新的通知，使用了 Flyway 就可以有效避免这个问题了。
所有的脚本，一旦执行了，就会在 flyway_schema_history 表中有记录，如果你不小心搞错了，可以手动从 flyway_schema_history 表中删除记录，然后修改 SQL 脚本后再重新启动（生产环境不建议）。
Flyway是如何工作的
Flyway工作流程如下：
1、项目启动，应用程序完成数据库连接池的建立后，Flyway自动运行。
2、初次使用时，Flyway会创建一个flyway_schema_history表，用于记录sql执行记录。
3、Flyway会扫描项目指定路径下(默认是classpath:db/migration)的所有sql脚本，与flyway_schema_history表脚本记录进行比对。如果数据库记录执行过的脚本记录，与项目中的sql脚本不一致，Flyway会报错并停止项目执行。
4、如果校验通过，则根据表中的sql记录最大版本号，忽略所有版本号不大于该版本的脚本。再按照版本号从小到大，逐个执行其余脚本。
项目中使用Flyway
首先，在pom文件中引入flyway的核心依赖包：
1、引入核心依赖包：
org.flywaydb flyway-core 5.2.4
这里使用5.2.4版本。经测试7.0.0版本与目前我们使用的springboot版本有冲突，会导致flyway不执行。因此我们尽量不要使用高版本的flyway。
2、配置文件：
简单配置一个属性即可使用
# 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
flyway的properties配置清单(属性未测试)：
# 对执行迁移时基准版本的描述. flyway.baseline-description #当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false. flyway.baseline-on-migrate =false #开始执行基准迁移时对现有的schema的版本打标签，默认值为1. flyway.baseline-version=1 #检查迁移脚本的位置是否存在，默认false. flyway.check-location=false #当发现校验错误时是否自动调用clean，默认false. flyway.clean-on-validation-error=false #是否开启flywary，默认true. flyway.enabled=true #设置迁移时的编码，默认UTF-8. flyway.encoding #当读取元数据表时是否忽略错误的迁移，默认false. flyway.ignore-failed-future-migration #当初始化好连接时要执行的SQL. flyway.init-sqls #迁移脚本的位置，默认db/migration. flyway.locations #是否允许无序的迁移，默认false. flyway.out-of-order #目标数据库的密码. flyway.password #设置每个placeholder的前缀，默认${. flyway.placeholder-prefix #是否要被替换，默认true. flyway.placeholder-replacementplaceholders #设置每个placeholder的后缀，默认}. flyway.placeholder-suffix #设置placeholder的value flyway.placeholders.[placeholder name] #设定需要flywary迁移的schema，大小写敏感，默认为连接默认的schema. flyway.schemas #迁移文件的前缀，默认为V. flyway.sql-migration-prefix #迁移脚本的文件名分隔符，默认__ flyway.sql-migration-separator #迁移脚本的后缀，默认为.sql flyway.sql-migration-suffix #使用的元数据表名，默认为schema_version flyway.tableflyway #迁移时使用的目标版本，默认为latest version flyway.target #迁移时使用的JDBC URL，如果没有指定的话，将使用配置的主数据源 flyway.url #迁移数据库的用户名 flyway.user #迁移时是否校验，默认为true flyway.validate-on-migrateflyway的yml配置清单(已测试，没问题，推荐使用yml格式的配置文件)
# 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 为 tr以上就是flyway实现java 自动升级SQL脚本的问题及解决方法的详细内容，更多请关注0133技术站其它相关文章！
