我们在我的项目中遇到了同样的问题，并决定对已经部署到生产环境的版本进行汇总。为了将增量更改汇总到一个文件中，我在数据库中从头开始运行迁移，然后将整个数据库转储（导出）回一个SQL文件中。我使用迁移的最新版本命名了该文件。在你的情况下V1_300__rollup.sql。然后，您可以继续添加新版本：V2_1、V2_2等。想卷起来的时候再重复

我们遇到了类似的问题：太多的数据库迁移脚本导致测试执行缓慢。在此之上，我们有相当复杂的环境来运行应用程序：所有测试都是针对空的docker数据库运行的，我们有几个不同数据库版本的部署（dev - latest，stage - some，prod - oldest）。
有两种情况：当dev/stage/prod中的所有版本对齐并且dev/stage在prod之前时。下面我将描述当您在所有环境中使用相同的DB版本时的解决方案。
第二种情况也有可能解决，但需要更多的努力来实施。一般方法-将DB模式合并到“最旧”DB版本，将最新的迁移脚本重命名为主要版本之后的新版本，并确保最新的DB更改不会应用两次（检查更改是否已应用）。
“所有envs DB版本已对齐”步骤：

• 创建“合并”DB脚本。您可以针对空数据库运行项目，并使用数据库类型特定的工具从中提取模式。
• 从配置的飞行路径位置删除（或移动）所有数据库迁移脚本文件，并替换为上一步中生成的文件。我建议创建新的主要版本，所以如果你有最新的V1_300，合并文件将有V2_0
• 在与V2_0脚本位置相同的位置创建beforeValidate.sql（see flyway docs），内容如下（MSSQL/AzureSQL示例）：

-- run baseline manually
if OBJECT_ID(SCHEMA_NAME() + '.flyway_schema_history', 'U') IS NOT NULL
    if exists(select 1
              from flyway_schema_history
              where version = 'YOU_FIRST_MIGRATION_VERSION_AFTER_BASELINE')
        begin
            begin
                declare @max_inst_rank int;
                select @max_inst_rank = MAX(installed_rank) from flyway_schema_history;
                delete from flyway_schema_history;
                INSERT INTO flyway_schema_history (installed_rank, version, description, type, script, checksum,
                                                   installed_by,
                                                   installed_on, execution_time, success)
                VALUES (@max_inst_rank + 1, 'YOUR_MERGED_VERSION', '<< Flyway Baseline >>', 'BASELINE', '<< Flyway Baseline >>', NULL,
                        'WHO_CREATED', GETDATE(), 0, 1);
            end;
        end;
GO

其中：

YOU_FIRST_MIGRATION_VERSION_AFTER_BASELINE-基线后第一次迁移的次数，例如1.0.1
YOUR_MERGED_VERSION-新的“合并”版本号，例如2.0.0
WHO_CREATED-创建记录的人

此脚本将在flyway根据迁移文件验证迁移DB记录之前运行，因此它将执行以下操作：

1. when flyway_schema_history is not exists（we are running on empty DB）- dong nothing
   1.当存在flyway_schema_history时

• 并且存在第一次迁移（例如1.0.1）-删除所有记录

在flyway_schema_history中创建新的基线，并将版本设置为2.0.0。由于数据库已经存在，因此不会进行实际的数据库更改。

• 和第一次迁移1.0.1不存在-什么都不做，因为我们已经做了所有必要的行动。

在所有这些操作和部署到所有环境的最后，您将在flyway_schema_history表中拥有V2.0.0文件和一条BASELINE记录。您可以从V2.0.1版本开始创建新的DB缓解脚本
您还可以将flyway_schema_history表记录移动到另一个表中，而不是出于审计目的进行删除。
beforeValidate.sql脚本将在每次服务器启动时运行，并且通常不执行任何操作，因为所有更改都已应用。当所有环境升级时，你可以从flyway文件夹中删除脚本。
在flyway 8.5.x，SpringBoot 2.7.x上验证