工具笔记
让 AI 写 PostgreSQL 索引迁移，先确认能否并发执行
CONCURRENTLY 减少阻塞写入，也改变迁移运行方式。
资料核验2026.11.12 · PostgreSQL · 以部署版本文档为准
一个大表要给经常用的查询补索引。把普通 CREATE INDEX 直接塞进发布迁移，可能在构建期间阻挡该表写入。PostgreSQL 提供 CONCURRENTLY，但这条语句不能在事务块内执行。
让助手从这一步开始
把迁移框架、目标表和部署约束交给助手。要求它先查框架是否默认包事务，再写并发建索引的独立步骤，给出失败后怎么识别无效索引。生产操作先只做方案，在测试库演练。
先检查迁移工具怎么包事务
在测试环境确认框架是否默认把迁移装进事务。需要并发建索引时，把操作独立出来并按工具支持的方式执行。它可能需要更久，也会等待相关事务。
中途失败可能留下无效索引。演练时记录如何识别该状态，重新执行前先按文档处理。
上线后同时查索引有效性和目标查询计划。名字出现了，查询也可能还没有使用它。
把问题变成可重跑的样例
在临时库开一条持续写测试表的连接，并运行迁移候选。记录运行时间与写入是否前进。再在独立试验里中断一次构建，检查 catalog 对该索引有效性的记录。只有在隔离环境确认恢复步骤后才安排线上窗口。
核对这几项输出
- 迁移在正确事务边界执行。
- 测试写入可继续。
- 失败后能辨认无效索引。
- 成功后目标查询计划可核对。
怎么判断改动能不能收
并发建索引并不承诺无等待，也不是所有迁移工具都允许单条跳过事务。让助手把前置条件和演练证据写进交接，避免部署时才发现运行器把语句包进事务。
演练前列出当前活跃连接、迁移事务策略和检查索引有效性的查询。若失败后留下无效索引，先判断是否由这次演练产生。部署时只按已审查的操作计划处理对应索引，不盲目重复执行整个迁移。
