克隆生产库后Flyway启动报错，无法修改flyway_schema_history表求方案

问题根源 #

生产环境的 flyway_schema_history 表是旧版本Flyway创建（或手动创建）的，缺少 installed_on 列的默认值约束；而新版本Flyway在插入迁移历史记录时，依赖该列的默认值自动填充，导致插入NULL值触发非空约束报错。

可行解决方案 #

方案1：低版本迁移脚本 + 启用Out-of-Order（最优） #

这是无需修改测试环境历史、且能兼容生产/测试环境的方案：

1. 新建迁移脚本 V0__add_default_constraint_to_flyway_schema_history.sql，内容为带存在性判断的SQL（避免重复执行报错）：

IF NOT EXISTS (SELECT * FROM sys.default_constraints 
               WHERE name = 'DF_flyway_schema_history_installed_on' 
               AND parent_object_id = OBJECT_ID('a.b.flyway_schema_history'))
BEGIN
    ALTER TABLE a.b.flyway_schema_history
    ADD CONSTRAINT DF_flyway_schema_history_installed_on 
    DEFAULT GETDATE() FOR installed_on;
END

2. 修改application.yaml配置，启用跨版本执行：

spring:
  flyway:
    out-of-order: true
    schemas: a
    # 移除baseline相关配置，因为已有历史表，baseline逻辑不会触发B开头脚本

3. 执行逻辑：
   • 生产环境现有迁移版本为V1、V2，V0版本更低，启用out-of-order后Flyway会优先执行该脚本，给installed_on列添加默认值，后续正常执行其他迁移脚本。
   • 测试环境已有V13版本，V0脚本执行时会检测到约束已存在（测试环境表由Flyway自动创建，自带默认值），判断语句会跳过ALTER操作，无报错风险。

方案2：不推荐的方案说明 #

你提到的「删除测试环境flyway_schema_history表重建」风险极高：会丢失测试环境的迁移历史记录，且需要协调测试环境的运维操作，完全没有必要采用。

若尝试调整现有脚本版本号（比如把默认值脚本设为V1，原有脚本递增版本），会导致生产环境出现版本冲突（生产已有V1、V2记录，新V1脚本会被视为未执行），引发更复杂的问题，同样不推荐。

为什么之前的Baseline配置无效？ #

baseline-on-migrate: true仅在不存在flyway_schema_history表时生效，用于初始化历史表；而B开头的基线脚本仅在手动执行flyway baseline命令时才会运行，自动迁移流程不会触发这类脚本，因此你的配置无法修改已存在的历史表结构。

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