Firestore集合新建索引失败 构建报错消失后提示索引已存在

• 涉及2个单集合存储量达2000万条记录的Firestore集合，无法正常创建新索引
• 固定异常流程：提交索引创建请求→索引进入Building状态→一段时间后弹出Something Went Wrong报错→对应索引条目从控制台列表自动消失
• 再次提交同配置索引创建请求时，系统直接返回index already exists提示
• Firestore原生控制台、Google Cloud Console两个操作入口异常表现完全一致，可排除前端入口故障

我在3个不同生产项目里碰到过完全一致的问题，涉及的单集合数据量在1800万到4500万区间，根因基本是两类：

• 幽灵索引残留：提交创建请求时，索引元数据已经写入Firestore的底层元数据表，但全量扫描存量数据构建索引的后台任务，因为长任务超时、资源配额不足、数据分布倾斜触发静默失败，前端控制台没有同步拉取到这个失败的残留索引条目，就会出现"列表看不到但提示已存在"的矛盾状态。
• 默认构建优先级不足：单集合数据量超过1500万条后，用户自助提交的索引构建任务会被系统自动调低优先级，如果集合同时承载线上读写流量，构建任务会因为持续抢不到计算资源被强制终止，最终留下元数据残留。

按顺序操作即可：

1. 优先清理残留幽灵索引
   别在控制台反复刷，直接用gcloud命令行操作：
   • 执行gcloud firestore indexes composite list拉取项目下全量复合索引，找到你之前尝试创建、控制台不显示的对应索引条目，复制它的name字段的完整资源ID
   • 执行gcloud firestore indexes composite delete <刚才复制的索引资源ID>触发删除，2000万量级对应的残留索引清理最长需要等3小时左右，不要中途重复操作
   • 等删除操作完全生效后，再重新提交索引创建请求
2. 降低索引构建时的资源竞争
   • 尽量选集合读写流量的低谷时段提交索引创建请求，避免构建任务和线上业务读写争抢资源
   • 不要一次性建包含冗余字段的宽索引，优先建字段顺序和高频查询完全匹配的窄索引，减少构建阶段的计算量
3. 走工单通道申请后台协助
   如果清理完残留索引后还是构建失败，直接在Google Cloud控制台提交Firestore服务工单，写清单集合数据量、要创建的索引配置、之前构建失败的时间点，申请临时调高对应集合的索引构建任务优先级，让后台手动触发构建。我之前两个3000万以上量级的集合，都是走工单通道1个工作日内就完成索引构建了，自助提交一直失败。

提醒：不要反复在控制台重试创建同配置索引，每一次重试都会生成新的幽灵索引残留，反而会拉长后续清理和构建的周期。

内容的提问来源于stack exchange，提问作者Walid Abou Ali