官网：https://flywaydb.org/documentation/
Github: https://github.com/flyway/flyway
为什么要迁移数据库？首先，让我们从头开始，假设我们有一个名为Shiny的项目，其主要可交付成果是一个名为Shiny Soft的软件，它连接到名为Shiny DB的数据库。
表示这一点的最简单图表可能如下所示：
我们有我们的软件和我们的数据库。伟大的。这很可能就是您所需要的。
但在大多数项目中，这种简单的世界观很快就会转化为：
我们现在不仅要处理我们环境的一个副本，而且还要处理几个。这带来了许多挑战。
我们一直很擅长在代码方面解决它们。
版本控制现在是通用的，每天都有更好的工具。我们有可重复的构建和持续集成。我们有明确定义的发布和部署流程。
但是数据库呢？
不幸的是，我们在那里做得并不好。许多项目仍然依赖于手动应用的 sql 脚本。有时甚至没有（这里或那里的快速 sql 语句来解决问题）。很快就会出现许多问题：
这台机器上的数据库处于什么状态？此脚本是否已应用？生产中的快速修复是否在之后的测试中应用？你如何设置一个新的数据库实例？
这些问题的答案往往是：我们不知道。
数据库迁移是重新控制这一混乱局面的好方法。
它们允许您：
从头开始重新创建数据库始终明确数据库处于什么状态以确定的方式从当前版本的数据库迁移到新版本 Flyway 的工作原理
最简单的情况是当您将Flyway指向一个空数据库时。
它将尝试定位其模式历史表。由于数据库是空的，Flyway 不会找到它，而是会 创建它。
您现在有一个默认情况下包含一个名为flyway_schema_history 的空表的数据库：
该表将用于跟踪数据库的状态。
紧接着 Flyway 将开始扫描文件系统或应用程序的类路径以进行迁移。它们可以用 Sql 或 Java 编写。
然后根据版本号对迁移进行排序并按顺序应用：
随着每次迁移的应用，架构历史表会相应地更新：
有了元数据和初始状态，我们现在可以讨论迁移到更新版本。
Flyway 将再次扫描文件系统或应用程序的类路径以进行迁移。根据模式历史记录表检查迁移。如果它们的版本号低于或等于标记为当前的版本之一，它们将被忽略。
剩余的迁移是待处理的迁移：可用，但未应用。
然后它们按版本号排序并按顺序执行：
架构历史表会相应更新：
就是这样！每当需要发展数据库时，无论是结构 (DDL) 还是参考数据 (DML)，只需创建一个版本号高于当前版本号的新迁移即可。下次 Flyway 启动时，它会找到它并相应地升级数据库。
Springboot 中使用(Maven)引入依赖
org.flywaydb flyway-core 8.5.4 org.flywaydb flyway-maven-plugin 8.5.4
配置
spring:
flyway:
enabled: true
encoding: UTF-8
clean-disabled: true
locations: classpath:db/migration
# sql文件命名规范：V版本号__描述.sql，例：V1.0__init_db.sql
sql-migration-prefix: V # V代表版本迁移，U代表撤销迁移，R代表可重复迁移
sql-migration-separator: __ # 分隔符：固定由两个下划线 __ 组成
sql-migration-suffixes: .sql # 后缀
validate-on-migrate: true # 执行迁移时是否自动调用验证
baseline-on-migrate: true # 迁移非空模式时是否自动调用基线
在resoures下 创建 db/migration
我们只需要将sql脚本放在 db/migration下，项目启动，即可自动同步数据库了
