MyBatis迁移将每个SQL文件分为两部分：
如何使用Flyway回滚版本？
答案 0 :(得分：74)
在FAQ中找到答案：
降级脚本/向下迁移怎么样？
Flyway不支持降级脚本。
虽然降级脚本（由Rails Migrations推广）的想法在理论上是一个很好的，但不幸的是它在实践中崩溃了。一旦你有破坏性的变化（删除，删除，截断，......），你就开始陷入困境。即使你不这样做，你最终也会创建自制的备份来恢复备份，这些备份也需要进行适当的测试。
降级脚本假设整个迁移失败。
迁移可能随时失败。如果您有10个语句，则第1个，第5个，第7个或第10个语句可能会失败。事先没有办法知道。编写降级脚本以回滚整个迁移。即使是非破坏性的变化，这也使它们变得无用。
维护数据库与当前在生产中部署的所有代码版本之间的向后兼容性。
这样一种失败的迁移不是灾难。旧版本的应用程序仍然与数据库兼容，因此您只需回滚应用程序代码，进行调查并采取纠正措施。
更好的解决方案是经过充分测试的适当的备份和恢复策略。
它独立于数据库结构，一旦经过测试并证明可以正常工作，任何迁移脚本都无法破解它。为获得最佳性能，如果您的基础架构支持此功能，我们建议您使用底层存储解决方案的快照技术。特别是对于更大的数据量，这可能比传统的备份和恢复快<强>几个数量级！
答案 1 :(得分：8)
自Flyway 5.0起支持此功能。可悲的是，它只是一个商业功能。
答案 2 :(得分：0)
我假设你需要一个回滚策略，例如合作伙伴在生产阶段失败，他的部署对您的发布至关重要。
您可以将您的flyway SQL脚本命名为： V氮化YourReleaseNumber＆gt; .000_＆lt;说明＆gt; .sql
现在你可以离开
V氮化YourReleaseNumber＆gt; .998_rollback.sql 用于回滚
并使 V＆lt; YourReleaseNumber＆gt; .999_reenroll.sql 重新注册。
在CI / CD环境中，部署作业后需要再增加2个作业（手动触发）。一个用于回滚，它运行回滚过程，包括flyway migrate。其他用于重新注册。
您只需要关心飞路中的目标配置
对于您的部署作业，您的目标应该是＆lt; YourReleaseNumber＆gt; .997
对于您的回滚作业＆lt; YourReleaseNumber＆gt; .998
当您启动新版本时，请确保您不会运行旧版本的回滚/重新滚动脚本。
如前所述，经过充分测试，备份和恢复策略是推荐的解决方案。
（sry for bad english）
答案 3 :(得分：-4)
我发现执行此操作的最佳方法是将数据库清除干净，然后将转发到您想要恢复的特定版本。
正如常见问题解答建议回滚脚本在理论上很好，但有些迁移无法回滚。 （例如，如果删除表，则恢复表DDL很容易，但恢复其包含的数据可能很困难。）