Flyway迁移未删除表求助：Spring Boot场景下异常排查

可能的原因 #

• 迁移脚本内容异常：校验和（checksum）为0通常意味着Flyway读取到的脚本内容为空，或者只有空白字符/注释。比如脚本文件未正确保存、DROP TABLE语句被误注释，甚至文件本身是空的。这种情况下Flyway会标记迁移成功，但实际没有执行任何有效SQL。
• 表名大小写不匹配：MySQL的表名大小写敏感性由lower_case_table_names参数控制。如果脚本中写的表名是project_register_maps，但数据库中实际表名是大写（如PROJECT_REGISTER_MAPS），且MySQL配置为区分大小写，DROP TABLE IF EXISTS会因找不到表而不执行删除操作，同时不会抛出异常。
• 数据库权限问题（概率较低）：虽然日志显示迁移成功，但如果执行迁移的数据库用户没有DROP TABLE权限，部分特殊场景下可能导致操作静默失败（不过这种情况Flyway通常会记录错误日志）。

解决步骤 #

1. 检查迁移脚本内容
   直接打开V35__delete_project_register_maps.sql文件，确认里面确实存在未被注释的DROP TABLE IF EXISTS project_register_maps;语句，文件不为空且没有多余空白导致Flyway无法识别有效SQL。

2. 核对表名大小写
   在MySQL中执行以下命令查看表名实际大小写：

   SHOW CREATE TABLE project_register_maps;
   

   确保脚本中的表名和实际表名完全一致。如果不一致，修改脚本中的表名匹配实际，或者调整MySQL的lower_case_table_names配置（需重启数据库，生产环境谨慎操作）。

3. 验证数据库用户权限
   执行以下SQL检查用户权限：

   SHOW GRANTS FOR 'root'@'localhost'; -- 替换为实际执行迁移的用户名和主机
   

   确认用户拥有DROP权限（通常包含在ALL PRIVILEGES或明确的DROP权限中）。

4. 修复Flyway校验和并重新执行
   如果脚本内容正常但校验和仍为0：

   • 先删除flyway_schema_history中对应记录：

     DELETE FROM flyway_schema_history WHERE installed_rank = 35;
     

   • 重新启动应用执行迁移，或使用Flyway的repair命令修复校验和后再执行迁移。

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