Flyway执行migrate报表已存在 如何在不删库情况下修复

核心原因很明确：flyway repair只会清理失败的迁移标记、修正checksum不一致的问题，不会自动把数据库里已经存在、但没在Flyway历史表里登记的建表操作标记为已执行，所以后续flyway migrate会尝试重新跑这个建表脚本，触发报错。以下是生产环境可用、无需删库丢数据的方案：

方案1：手动补全Flyway迁移历史（最推荐，无侵入） #

这个方案完全不改动现有业务表结构和数据，只补全Flyway的元数据记录，是生产环境首选：

• 先定位报错对应的迁移脚本，确认它的完整文件名（比如V2.7__create_order_ext_table.sql）、版本号、脚本内容，确保当前库里已经存在的TABLE_NAME表结构和脚本里的定义完全一致，避免后续迁移因为结构不匹配报错。
• 本地在项目目录执行flyway info，拿到这个脚本对应的checksum值，记下来。
• 连接目标业务库，查询Flyway元数据表flyway_schema_history，确认这个版本的迁移确实没有成功执行的记录。
• 往flyway_schema_history表插入一条该脚本的成功执行记录，字段参考如下填写：
  • installed_rank：取当前表内已有的最大installed_rank值+1
  • version：脚本对应的版本号，比如上面例子里的2.7
  • description：脚本文件名里双下划线后的描述部分，比如create order ext table
  • type：填SQL
  • script：填迁移脚本的完整相对路径，和你项目里的路径完全一致，比如db/migration/V2.7__create_order_ext_table.sql
  • checksum：之前从flyway info拿到的脚本checksum值
  • installed_by：你当前操作数据库使用的账号名即可
  • installed_on：填当前数据库时间
  • execution_time：填个合理的数值即可，比如20
  • success：填1（代表执行成功）
• 记录插入完成后，重新执行flyway migrate即可，Flyway会识别到这个脚本已经执行过，跳过建表步骤继续跑后续的迁移。

方案2：修改建表脚本为容错写法（适合不方便改元数据表的场景） #

如果你没有直接操作flyway_schema_history表的权限，可以用这个方案：

• 先备份现有TABLE_NAME表的结构和全量数据，防止意外。
• 把原脚本里的建表语句从CREATE TABLE TABLE_NAME (...)改成CREATE TABLE IF NOT EXISTS TABLE_NAME (...)。
• 确认现有表结构和脚本里定义的字段、索引、约束完全一致，避免结构偏差。
• 先执行一次flyway repair清理之前的失败标记，再执行flyway migrate，此时建表语句因为带了IF NOT EXISTS判断，遇到已存在的表不会抛出异常，Flyway会正常把这个脚本标记为执行成功，后续流程不受影响。

注意：不要为了图省事直接把报错的建表脚本删掉或者改名，会导致开发、测试、生产环境的迁移脚本版本不一致，后续上线会埋非常难排查的隐患，这种操作仅适合本地临时调试环境用，绝对不能在生产、公共测试环境操作。所有生产环境操作前，务必先做全库备份。

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