执行CREATE INDEX CONCURRENTLY失败后，再试一次却提示同名对象已存在。在PostgreSQL里，并发构建可能先登记索引再完成扫描，因此失败后仍可能看到一个无效索引。
先核对索引状态和构建是否仍在进行
用psql的\d+ public.orders看索引是否标记为INVALID，也可以查询SELECT indexrelid::regclass, indisvalid, indisready, indisunique FROM pg_index WHERE indrelid = to_regclass('public.orders');。表名须换成实际对象。
再查pg_stat_progress_create_index与原会话日志。并发构建过程本来就可能暂时显示无效；先确认原任务已失败退出，别把正在建的索引误删。
无效索引为何需要处理
查询规划器不能使用未标记有效的索引。视构建失败阶段而定，残留索引可能仍会增加写入维护成本。并发创建唯一索引时，若第二次扫描失败，残留索引还可能继续执行唯一性检查。INVALID不等于没有任何业务影响。
先处理根因，再选择删除或重建
先检查失败原因是重复数据、死锁、超时还是资源耗尽。对已确认无依赖的普通残留索引，可在维护计划内执行DROP INDEX CONCURRENTLY public.orders_customer_idx;，再执行原定义的CREATE INDEX CONCURRENTLY。并发删除与并发创建都不能放进显式事务块。
若索引依赖约束、涉及分区或本次其实是并发重建，应先查看原定义和依赖，按目标版本文档选择流程。不要用CASCADE快速清掉名字冲突。
REINDEX适合哪些情况
PostgreSQL 12及以后支持并发重建。对无效索引，能否使用REINDEX INDEX CONCURRENTLY要核对版本、索引类型和依赖限制。若残留来自并发REINDEX，_ccnew与_ccold指向的对象不同，不能只靠后缀决定删除哪一个。
验收看状态，也看业务查询
用萤光云或LightNode的隔离VPS验证同版本迁移脚本不会把并发语句包在事务里。修复后确认预期索引的indisvalid为真，并用代表性查询的EXPLAIN检查计划。查询未选该索引也不必然是故障，还要结合选择性、统计和成本判断。
FAQ
并发建索引能放进BEGIN吗？ 不能；让迁移工具对这一步关闭事务包装。
使用IF NOT EXISTS能修复无效索引吗？ 不会重建已存在的同名索引。
建到一半能删除吗？ 先核对进度并有序处理原任务，再判断残留。
普通DROP INDEX有什么代价？ 可能阻塞对表的访问，应按锁影响选维护窗口。
唯一索引失败后能直接重试吗？ 先找出并按业务规则处理重复数据，再重建。
温馨提示
保留原索引DDL、失败日志和索引所依赖的对象。若生产写入正在报唯一性冲突，先确认是否与残留索引相关，再决定回滚方案。
