从 AI 接口超时，追到一次未完成的数据库变更
假设企业把订单查询接入 AI 助手，试运行时发现某类查询缓慢，交付工程师准备给业务表增加索引。变更任务中途报错，助手仍能回答一部分问题，于是团队打算再点一次执行。这是假设场景，不是客户案例。真正需要先确认的是：报错前创建了什么对象，业务写入是否受到影响，应用侧的重试是否还在继续。
FDE 贴近现场交付 AI 系统时，经常需要协调应用、数据库与业务负责人。用户看到的是回答慢，底层修复却可能影响共用数据库。本文只讨论并发建索引失败的状态核验，不把增加索引视为所有 AI 查询延迟的通用解法。模型耗时、外部接口或不合适的查询结构，仍要分别排查。
官方文档提醒：并发创建也会留下失败对象
PostgreSQL 18 文档说明，CREATE INDEX CONCURRENTLY 可以避免阻断表上的正常并发写入，但需要额外扫描和等待，CPU 与 I/O 开销仍可能拖慢其他操作。并发不代表没有业务影响。
扫描过程中若发生死锁或唯一性冲突，创建可能失败并留下 INVALID 索引：它不会用于查询，却仍增加更新开销。唯一索引还有额外边界，第二次扫描阶段失败后，无效对象仍可能继续执行唯一性检查。官方给出的恢复方向包括删除后重新创建，或使用 REINDEX INDEX CONCURRENTLY。
这几条行为说明了为什么不能只看任务红绿灯。报错代表该次命令未完成，并不能证明数据库已恢复到变更前状态。具体采取哪种恢复方式，应由了解依赖关系和写入要求的数据库负责人判断，不能让 AI 助手根据错误文字直接自动删除对象。
重试前先留一份可复核的现场记录
建议交付单先记录目标库、模式、表、索引名称与完整定义，再保存任务日志、失败阶段和实际数据库版本。工程师可以通过只读方式查看对象状态，例如核对 psql 的表结构输出中是否出现 INVALID。对照对象时要同时看表与定义，避免把同名对象误当成此次变更的产物。
现场记录还应包含应用侧现象：哪些请求超时、写入是否出现新的唯一性错误、任务取消后错误是否仍持续。保留必要的错误类别与请求标识即可，不把完整客户数据复制进智能体上下文。记录的目的，是让数据库负责人能重建故障过程，而不是堆积无法关联的截图。
若查不到目标对象，或对象已有效，也不能沿用“无效索引待删除”的结论。此时应回到日志与实际状态重新定位。建议把核验结果分成无残留、存在无效对象、对象有效但效果未验证三种，再决定下一步，避免所有失败都落到同一条自动重试分支。
恢复方案要同时覆盖业务写入与发布工具
恢复前建议暂停同一目标上的重复变更任务，明确由谁执行、谁观察业务，以及出现何种信号就停止。暂停变更不等于停止全部业务流量，具体范围取决于系统是否允许安全隔离。若涉及唯一性错误，先确认写入规则和已有重复数据，不能把解除校验当成恢复服务的默认办法。
官方文档还规定，并发建索引不能放进事务块，同一张表一次只能有一个并发索引创建任务。因此，团队需要检查迁移工具是否默认把所有语句包在一个事务里，以及流水线是否可能重复启动同一项工作。把命令手工执行成功，并不证明放入现有发布工具后也可成功。
建议先在隔离环境复现所选恢复路径，核对工具行为，再安排真实变更窗口。生产库上的删除、重建或取消操作应执行既有变更审批与备份规范。没有足够现场证据时，交付状态应记为“恢复方案待确认”，而不是为了让任务完成而轮流尝试多条修改命令。
验收不能只交一张索引存在的截图
第一层建议验对象状态与定义：目标表正确，字段顺序、条件与预期一致，没有未经解释的失败残留。第二层验业务写入：使用已获授权的测试流程检查新增、修改与重复值处理，确认错误与业务规则相符。测试数据的清理方式也应在执行前约定。
第三层再验查询效果。固定一组有代表性的参数、数据规模与并发条件，记录变更前后执行计划、响应分布与数据库负载。查询没有选择新索引时，应分析计划与查询条件，不能把“已建好”直接写成“已加速”。性能阈值由业务需求和基线决定，本文不给出通用百分比承诺。
最后回到 AI 服务入口，核对数据库超时是否被正确传递、助手是否把未完成查询误说成无结果，以及旧的重试任务是否已停止。只有数据库对象、业务读写和应用表现都有证据，交付记录才适合从“执行过恢复”推进到“本次范围验收通过”。
把失败分支纳入下一次交付
对反复部署到不同客户环境的 AI 服务，可以将此次教训落实为一张短清单：运行前确认版本和工具事务行为；失败后只读核验对象；选定恢复路径后单人执行；最后保存读写与入口验收证据。它比复制一串 SQL 更有复用价值，因为不同现场仍能据此判断哪些条件尚未满足。
这套方法适用于使用 PostgreSQL 18、确实需要索引变更的集成场景。它不替代数据库设计审查，也不直接覆盖分区表、第三方扩展索引或其他版本。交付负责人应把未验证范围写进交接单，让后续维护者知道本次确认了什么、还有什么需要另测。
要点总结
- 先只读核验目标对象、失败日志与业务写入状态，再由数据库负责人确定恢复路径；不要仅根据命令报错重跑。
- 不是。官方文档说明它仍有更新开销，特定失败阶段的唯一索引还可能继续执行唯一性检查。
- 不是。本文依据 PostgreSQL 18 既有文档进行方法分析，没有客户生产测试，也不承诺加速幅度。
参考来源说明
数据库行为以所引 PostgreSQL 18 文档为依据；业务场景、交付步骤与验收建议为编辑分析，未在客户生产库实测，不承诺性能收益。其他版本、扩展与托管平台需另行验证。