替换未执行成功的Flyway失效脚本的可行方案咨询

前提：原脚本V1_0_15_1__anytext.sql因占位符冲突执行失败并回滚，未对数据库产生持久化变更，Flyway的schema_version表中该版本状态为failed。

• 方案1：覆盖原文件
  不可行。Flyway通过文件名和schema_version记录追踪版本，即便覆盖原文件，Flyway仍会识别到该版本已处于失败状态，默认不会重新执行。若强行用flyway repair修改状态后执行，会导致不同环境的版本记录不一致，增加维护风险，违背Flyway的版本管控原则。

• 方案2：保留失效脚本，新增V1_0_15_2__anytext.sql
  完全可行，这是最符合Flyway最佳实践的方案。原脚本未成功执行，数据库中无对应有效变更，新增更高版本的脚本并写入修正后的SQL逻辑，Flyway会按版本递增顺序自动执行新脚本。此方案无需修改历史记录，跨环境同步仅需新增文件，风险低且版本轨迹清晰。

• 方案3：保留失效脚本，新增V1_0_15_1_1__anytext.sql
  理论可行但操作冗余。Flyway支持补丁版本命名，但需先处理schema_version中V1_0_15_1的失败状态——要么用flyway repair标记为ignored，要么手动删除该记录，否则Flyway会因检测到失败版本终止执行。相比方案2多了额外的状态修复步骤，维护复杂度更高，不推荐作为首选。

结论：优先选择方案2，操作简单合规，适配Flyway的版本管理逻辑。

内容的提问来源于stack exchange，提问作者Whome