AI 数据库迁移为何过了 CI 仍会出故障

AI 写的数据库迁移通过 CI，部署到 staging 后却引发锁阻塞。dev.to 的这篇文章用一个明确标注为「示意重建」的案例，讨论空库测试如何掩盖大表迁移风险，并提出用原始日志还原时间线、用持续执行的检查关卡约束迁移。它不是某家公司的真实事故记录。

目前能确认什么

案例中，agent 给一张八千万行的表添加 btree 索引。迁移在空 CI 数据库上十一秒完成，部署结束九分钟后，staging 出现锁阻塞。这些数字属于示意案例，不能当作产品性能数据。

索引可以帮助数据库查找数据，但创建索引也需要处理已有数据，并涉及锁。空表上执行成功，无法证明同一条语句在大表和并发访问下仍然安全。

作者提出，在一次性 PostgreSQL 数据库中准备接近真实表规模的数据，再执行迁移检查；同时把检查要求写入 AGENTS.md，并让复盘时间线引用提交、部署等原始记录。

CI 通过能证明什么，取决于它实际测了什么。

我的判断

对程序员最直接的提醒是：审查 schema 变更时，代码行数不能代表风险。即使只有一条建索引语句，也应交代表规模、锁类型，以及执行期间哪些访问可能受影响。agent 缺少这些上下文，审查者也不能只看 SQL 是否写对。

节选中的检查脚本还有一个边界：lock_timeout=2s 限制的是等待获取锁的时间，不是拿到锁后的持锁时长；statement_timeout=30s 才限制语句执行时间。因此，不能把它解读成「超过两秒的锁影响都能拦住」。

真实并发负载如何模拟、测试数据如何持续贴近业务、检查失败后如何调整迁移，现有节选没有讲清。这个关卡能补上空库测试的盲区，但还不足以单独证明部署安全。