flyway Increase reliability of deployments by versioning your database.
Flyway是一个开源的数据库迁移工具。
它强烈支持简单性和约定而不是配置。
它仅基于 7 个基本命令：Migrate, Clean, Info, Validate, Undo, Baseline and Repair.
迁移可以用 SQL（支持特定于数据库的语法（例如 PL/SQL、T-SQL 等））或 Java（用于高级数据转换或处理 LOB）编写。
当然，请见以下 Flyway 命令及其作用的清单：
flyway info：
显示当前数据库的信息，包括当前的迁移版本、已应用的迁移数量等。
flyway validate：
验证迁移脚本的合法性，检查迁移脚本是否存在语法错误或其他问题。
flyway migrate：
执行数据库迁移，将未应用的迁移脚本应用到目标数据库，使数据库结构与目标版本一致。
flyway clean：
删除所有已应用的迁移脚本，将数据库恢复到初始状态，适用于测试环境或重新构建数据库。
flyway baseline：
创建初始基线版本，在现有数据库上启动迁移控制，对已经存在但未经版本控制的数据库很有用。
flyway repair：
修复数据库的元数据与实际状态不一致问题，重新计算已应用的迁移版本。
flyway undo：
撤销上一次应用的迁移，将数据库结构回滚到上一个版本。
flyway history：
查看已应用的迁移历史记录，包括迁移版本、描述、状态等信息。
Snapshot
在项目的一生中，可以在许多迁移中创建和破坏许多数据库对象，这些迁移留下了漫长的迁移历史，需要应用这些迁移的历史，以使新的环境达到速度。
取而代之的是，您可能希望添加一个累积的迁移，该迁移代表所有这些迁移而不受破坏现有环境的应用后，该迁移代表数据库的状态。
Flyway为您提供了一种使用基线迁移来实现此目的的方法。
基线迁移以 B 为前缀，后跟它们代表的数据库版本。
例如：B5__my_database.sql 表示应用 V5 及之前的所有版本化迁移后数据库的状态。
仅在部署到新环境时才使用基线迁移。
Flyway 有许多不同的参数可以设置来配置其行为。
这些参数可以通过多种不同的方式设置，具体取决于您使用 Flyway 的方式。
如果使用命令行，则可以通过命令行参数（例如 ./flyway -url=jdbc:h2:mem:flyway info）、配置文件或环境变量（例如 FLYWAY_URL=jdbc:h2:mem:flyway ）。
如果使用 api，可以通过调用 Flyway.configure() 返回的配置对象上的方法来设置配置参数（例如 Flyway.configure().url("jdbc:h2:mem:flyway").load()），
我们经常遇到有关 Flyway 解析器无法处理某些 sql 脚本的错误。
创建此页面是为了记录一些已知问题、怪异现象和解决方法。
如果所有解决方法都不适合您，或者您认为该解决方法出于任何原因不适合，请创建一个包含复制步骤的 GitHub 问题，包括文件内容，或者在可能的情况下附加文件本身。
如果您看到任何错误消息“分隔符已在语句内更改”、“语句不完整”或“无法将块深度减小到 0 以下”，则可能是因为 Flyway 的控制流处理遇到错误。 这可能是由多种不同的原因造成的：
可能是因为尚不支持特定关键字（在这种情况下，请创建一个 Github 问题）。
这可能是因为您尚未关闭该块（例如，IF 未由 END IF 关闭）。
这可能是因为您使用控制流关键字作为变量名（Flyway 不支持）。 控制流关键字最常见的是 BEGIN 和 END，但也可能包括 IF、CASE、REPEAT、WHILE 等，具体取决于数据库类型。
在项目的生命周期中，可能会在多次迁移中创建和销毁许多数据库对象，这会留下漫长的迁移历史，需要应用这些迁移历史才能使新环境加快速度。
相反，您可能希望添加单个累积迁移来表示应用所有这些迁移后数据库的状态，而不破坏现有环境。
基线迁移可以让您实现这一目标。 这些是一种新类型的迁移，与版本化迁移类似，只是以 B 作为前缀。
在现有部署中，它们没有任何作用，因为您的数据库已经位于需要的位置。
在新环境中，首先应用最新版本的基线迁移，以便在应用后续迁移之前使数据库加快速度。 任何版本早于最新基线迁移版本的迁移都不会应用，并被视为被忽略。
