这个问题我之前用Flyway 3.x的时候也碰到过，核心是flyway.baselineOnMigrate=true的默认行为和你的迁移文件版本号冲突了：

• 当开启baselineOnMigrate=true时，Flyway检测到galaxybadge schema为空但没有元数据表（schema_version），就会自动创建这个元数据表，并把当前空schema的状态标记为默认基线版本1。
• 你的第一个迁移文件是V1__create_stats.sql，版本号正好是1。Flyway会认为这个版本的迁移已经通过基线完成了，直接跳过执行；而V2的迁移因为依赖V1的表（或是Flyway的版本校验逻辑），也不会被执行，最终导致目标表完全没生成。

下面提供几个可行的方案，按推荐程度排序：

方案1：修改基线版本为0（最优雅） #

这个方案不需要改动迁移文件，只需要调整配置：

1. 登录MySQL，删除自动生成的schema_version表：

DROP TABLE galaxybadge.schema_version;

2. 在application.properties中添加一行配置，把基线版本设为0：

flyway.baselineVersion=0

确保flyway.baselineOnMigrate=true的配置保留。
3. 重启Spring Boot应用。这时候Flyway会重新创建schema_version表，把空schema标记为版本0的基线，然后依次执行版本1和2的迁移文件，目标表就会正常生成了。

方案2：重命名迁移文件版本号 #

如果不想调整配置，可以修改迁移文件的版本号，让它们高于默认的基线版本1：

1. 把src/main/resources/db/migration/下的文件重命名：
   • V1__create_stats.sql → V2__create_stats.sql
   • V2__create_sources.sql → V3__create_sources.sql
2. 删除MySQL中的schema_version表，重启应用。Flyway会标记基线版本1，然后执行版本2和3的迁移。

方案3：手动执行基线命令（适合生产环境） #

如果是生产环境，不想删除元数据表，可以用Flyway命令行工具先设置基线版本为0：

1. 执行基线命令（替换成你的数据库连接信息）：

flyway baseline -url=jdbc:mysql://localhost/galaxybadge -user=你的数据库用户名 -password=你的数据库密码 -baselineVersion=0

2. 重启Spring Boot应用，Flyway会自动执行V1和V2的迁移文件。

为了确保迁移顺利执行，你可以再确认几个细节：

• 迁移文件的命名完全符合Flyway规范：V<版本号>__<描述>.sql（注意是两个下划线）
• 数据库连接配置正确，Flyway能正常访问galaxybadge schema
• 迁移文件本身没有SQL语法错误

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