针对你的Flyway迁移问题，我绝对推荐方案1：创建版本36的迁移文件执行删除列操作，同时强烈反对方案2——下面详细解释原因和其他可选方案：

优先推荐方案1：新增版本36的删除迁移 #

这是完全符合Flyway核心设计原则的做法，Flyway的核心思想就是已执行的迁移文件不可修改、不可删除，所有变更都要通过新增迁移文件来完成。

虽然看起来多了一个“冗余文件”，但这些文件其实是数据库变更的完整历史记录——后续哪天需要排查问题（比如想知道abc列什么时候被添加、什么时候被移除），直接查看迁移文件就能一目了然，这对维护数据库的可追溯性至关重要。

具体操作非常简单：

1. 创建迁移文件V36__drop_abc_column_from_xyz.sql
2. 在文件中写入SQL语句：ALTER TABLE xyz DROP COLUMN abc;
3. 正常执行Flyway迁移命令即可完成删除

为什么方案2（删除版本20的迁移文件）绝对不可行？ #

这个方案存在致命风险，尤其是在生产环境：

• 生产环境直接报错：生产环境的flyway_schema_history表已经记录了版本20的执行记录，当你删除本地的版本20文件后，下次在生产环境运行Flyway时，它会检测到已记录的迁移（版本20）对应的文件缺失，直接触发MissingMigrationException，中断所有后续迁移操作，这会导致生产环境的数据库变更完全停摆。
• 破坏环境一致性：开发、测试、生产环境的迁移文件集必须完全一致。删除版本20文件后，新搭建的环境（比如新的测试环境）不会执行添加abc列的操作，而老环境（比如生产）原本有这个列，这就造成了环境不一致，后续的数据库变更很容易出现兼容性问题。

其他替代方案 #

1. Flyway Pro/Enterprise版的Undo迁移 #

如果你使用的是付费的Flyway Pro或Enterprise版，可以利用Undo迁移功能来撤销版本20的变更：

• 创建Undo迁移文件U20__undo_add_abc_column_to_xyz.sql
• 在文件中写入撤销语句：ALTER TABLE xyz DROP COLUMN abc;
• 执行flyway undo命令即可撤销版本20的操作

不过这个方案需要付费版本支持，社区版没有Undo功能。

2. 合并迁移（仅适用于未上线环境） #

如果版本20的迁移还没有在生产环境执行，仅在开发/测试环境中存在，你可以考虑合并迁移：

1. 从版本20的迁移文件中移除添加abc列的语句
2. 清理掉开发/测试环境flyway_schema_history表中版本20的记录
3. 重新执行Flyway迁移

⚠️ 注意：这个操作绝对不能在生产环境进行，生产环境的迁移历史必须严格保留，任何修改都可能导致严重的一致性问题。

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