Flyway迁移机制与校验和
flyway是一个强大的数据库迁移工具，它通过版本化的脚本来管理数据库模式的演进。每次执行flyway:migrate命令时，flyway都会：
- 扫描项目中的迁移脚本（SQL文件或Java类）。
- 将这些脚本与数据库中flyway_schema_history表记录的已执行迁移进行比对。
- 对于每个已执行的迁移，Flyway会计算其当前脚本的校验和（checksum），并与flyway_schema_history表中记录的校验和进行比较。
校验和是Flyway确保数据库历史完整性的核心机制。一旦一个迁移脚本成功执行并记录在flyway_schema_history表中，其对应的校验和就会被固定。如果该脚本的内容在之后被修改，那么其重新计算的校验和将与表中记录的不同，Flyway就会检测到不一致。
“Future”状态的产生与影响
在提供的案例中，用户首先成功执行了V1、V2（SQL）和V3（Java）迁移。此时，flyway_schema_history表中记录了这三个迁移及其对应的校验和。当用户修改了V3 Java类（例如，添加了一行System.out.println），并再次运行flyway:info时，Flyway检测到：
- 数据库中已存在版本3的迁移记录。
- 本地V3 Java脚本的校验和与flyway_schema_history表中版本3的记录不匹配。
在这种情况下，flyway:info命令会将本地的V3迁移标记为“Future”状态。这里的“Future”并非指尚未执行的未来版本，而是表示Flyway发现一个本地脚本，其版本号与数据库中已应用的某个版本相同，但内容（校验和）不一致。Flyway认为数据库中的版本3是“权威”的，而本地被修改的V3脚本则被视为一个“未来的”、不兼容的或无效的同一版本。
随后尝试运行mvn flyway:migrate时，Flyway会给出如下警告：
[WARNING] Schema "PUBLIC" has a version (3) that is newer than the latest available migration (2) ! [INFO] Schema "PUBLIC" is up to date. No migration necessary.
这个警告的含义是：Flyway发现数据库的当前版本是3。然而，由于本地V3脚本的校验和不匹配，Flyway无法将其视为一个有效的、可信的迁移脚本。因此，在Flyway看来，它所能识别的“最新可用迁移”是V2。结果就是，数据库的实际版本（3）比Flyway当前信任的本地最新版本（2）“更新”，这表明数据库状态与本地可信脚本集之间存在不一致。Flyway因此无法执行任何新的迁移（例如V4），因为它无法解决V3的校验和问题，并且认为数据库已经“领先”于它所能识别的有效迁移。
解决方案（开发环境）
在开发环境中，当不小心修改了已执行的迁移脚本导致“Future”状态时，通常有以下几种处理方式。请注意，以下方法主要适用于开发和测试环境，在生产环境中应严格避免修改已执行的脚本。
-
回滚并重新迁移（推荐） 最干净的方法是回滚数据库到问题迁移发生之前的状态，然后重新执行迁移。这通常意味着：
- 删除数据库（如果是H2文件数据库，可以直接删除文件）。
- 确保本地的迁移脚本（包括修改后的V3）是最终正确的版本。
- 再次运行mvn flyway:migrate。
-
手动修改flyway_schema_history表 如果不想完全回滚数据库，可以手动修改flyway_schema_history表来解决校验和不匹配问题。这种方法需要谨慎操作，并确保你完全理解其影响。
-
步骤一：删除冲突的迁移记录
连接到你的数据库，并删除导致“Future”状态的迁移记录。在案例中，是版本3的记录：
DELETE FROM flyway_schema_history WHERE version = 3;
-
步骤二：重新执行迁移
在删除了冲突记录后，Flyway会认为版本3的迁移尚未执行。此时，确保本地V3脚本是正确的，然后重新运行迁移命令：
mvn flyway:migrate
Flyway将重新计算V3脚本的校验和，并将其作为新的记录插入到flyway_schema_history表中。此后，新的迁移（如V4）也可以正常添加和执行。
-
步骤一：删除冲突的迁移记录
连接到你的数据库，并删除导致“Future”状态的迁移记录。在案例中，是版本3的记录：
生产环境下的最佳实践与注意事项
在生产环境中，Flyway的“Future”状态或校验和不匹配是严重错误，必须严格避免。一旦迁移脚本被应用到生产数据库，它就成为数据库历史的不可变部分。任何对已执行脚本的修改都可能导致数据不一致、迁移失败，甚至数据丢失。
核心原则：
- 不可变性：一旦迁移脚本被应用，绝不允许修改其内容。
- 新版本：所有对数据库模式的变更都应通过创建新的迁移脚本（例如，V4、V5等）来实现。如果需要修正已应用脚本的功能，应创建新的脚本来执行修正逻辑。
- 版本控制：Flyway迁移脚本应纳入版本控制系统（如Git），并遵循严格的审批和发布流程。
- 持续集成/持续部署（CI/CD）：在CI/CD流程中集成Flyway，确保在部署到生产环境之前，所有迁移都在测试环境中充分验证。
总结
Flyway的“Future”状态是其校验和机制在检测到已应用脚本被修改时的一种表现。在开发环境中，可以通过回滚数据库或谨慎修改flyway_schema_history表来解决。但在生产环境中，避免此问题的唯一方法是严格遵守“不可变性”原则，即永不修改已执行的迁移脚本。理解并遵循这些最佳实践，是有效利用Flyway进行数据库版本控制的关键。
