测试数据工厂如何自动感知 Schema 变更：新增 NOT NULL 列 / 枚举扩展 / 索引签名变化后，CI 里「造数覆盖度」门禁有没有可落地做法？

背景

5 年测试开发，负责一条 B 端 SaaS 的订单 + 支付链路（Java 17 + JUnit 5 + Testcontainers + MySQL 8.0.34）。团队约 800 个接口用例，测试数据用一套自研 Fixture 工厂（Python 脚本生成 SQL INSERT 模板，按表维护）。生产库 40+ 张表，Schema 由 DBA 管，DDL 走 ticket 审批，变更频率大约 2–3 次/周。

现象（最近 3 个月踩了 4 次「测试全绿、上线后数据形态差异翻车」）

1. 新增 NOT NULL 列 + 窗口期 NULL：生产 t_order 新增 channel_source VARCHAR(32) NOT NULL DEFAULT 'WEB'，DDL 先 ALTER 后补历史数据，中间有 2 小时窗口期存在 NULL。我们的 Fixture 没传这个字段 → 测试走 DEFAULT 全绿 → 上线后聚合报表碰到 NULL 行 NPE。
2. 枚举扩展漏覆盖：order_status 新增 REFUNDING，我们的断言只覆盖了 5 个旧枚举值 → 回归全绿 → 上线后一个 switch-case 漏了 REFUNDING，200 多笔订单卡死 6 小时。
3. 唯一索引签名变化：索引从 (tenant_id, order_no) 改成 (tenant_id, order_no, idempotency_key)，造数脚本还在用旧三元组 → CI 偶现唯一键冲突，排查了 2 小时才发现是索引变了。
4. 列类型变更：某计数字段从 INT 改 BIGINT，测试数据量小（几千行）没暴露，生产 2^31 行后溢出。

已尝试的排查与结果

• CI 里加 SHOW CREATE TABLE 对比：拉 staging 和 Fixture 模板做 diff，只告警不阻塞。跑了 3 周后告警疲劳（DDL 频率高 + 很多变更跟测试无关），团队开始忽略，形同虚设。
• 人肉同步：要求 DBA 在 DDL ticket 里 @测试负责人。4 次事故里 2 次是忘了 @，1 次是 @ 了但测试没来得及改 Fixture 就发版了。
• ArchUnit 静态检查：用 ArchUnit 规则检查 Java 测试对象是否包含所有 DB 列。维护成本高，每加一个字段都要改规则，而且覆盖不了枚举扩展和索引签名变化。
• Testcontainers 里跑 migration：试过在 CI 里先跑 Flyway migration 再跑用例，能暴露「缺列」问题，但枚举扩展和索引签名变化仍然检测不到（因为 INSERT 不报错，只是语义上没覆盖新值）。

期望得到的答案形态

想听到具体落地的做法，不限工具链（自研脚本 / DBA 工具链集成 / Testcontainers 扩展 / CI plugin 都行），核心问题是：

1. 有没有团队在 CI 里做了「测试数据覆盖度门禁」？ 具体怎么做的——是从生产 schema（或 staging DDL）自动拉列清单 + 枚举值 + 索引签名，和 Fixture 工厂的 INSERT 模板做结构化 diff，缺列 / 缺枚举值 / 索引签名不一致时直接 fail？还是用 contract test 的思路把 schema 当 provider contract、Fixture 工厂当 consumer？
2. 告警疲劳怎么破？ DDL 变更频率 2–3 次/周，不可能每次都让测试手动改 Fixture。怎么区分「必须改」和「可以忽略」？有没有自动判断「这个 DDL 变更是否影响现有 Fixture 覆盖」的方法？
3. 枚举扩展的覆盖度怎么自动检测？ SHOW CREATE TABLE 看不到枚举值（MySQL 枚举是列定义里的），有没有比 SELECT DISTINCT 更可靠的自动枚举值发现手段（比如从代码里的 enum 类 / 配置中心拉）？

参考：社区已有不少关于测试数据工厂收口（id=945、id=182）和测试环境 vs 生产数据差异（id=203、id=855）的讨论，但聚焦于「Schema 变更 → Fixture 自动感知 → CI 门禁」这条链路的，我还没看到，所以来问。