Firestore复合索引字段顺序对查询性能的影响及索引选择疑问

问题背景 #

我的Firestore查询执行时间超过4秒，查询结构如下：

db
  .collection('testCollection')
  .where('fieldA', '==', 1)
  .where('fieldB', '==', 2)
  .where('fieldC', '==', 3)

自动生成的复合索引为fieldC (ASC), fieldB (ASC), fieldA (ASC)（称为Index Alpha），字段基数分布为：

• fieldA（基数最高）
• fieldB（基数次之）
• fieldC（基数最低）

1. 手动创建Index Beta能否提升查询速度？ #

能。Firestore的复合索引是按前缀顺序逐层过滤数据的，将高基数字段放在索引前缀，能更快缩小结果集范围：

• Index Beta把最高基数的fieldA放在最前面，查询时会先筛选出所有fieldA=1的文档，这一步就能排除绝大多数不符合条件的数据；接着用fieldB=2进一步过滤，最后用fieldC=3收尾，每一步的过滤效率都远高于Index Alpha。
• 反观Index Alpha，先从基数最低的fieldC=3开始筛选，这一步会保留大量无关文档，后续过滤步骤需要处理更多数据，自然拖慢查询速度。

因此，高基数字段前置的Index Beta能大幅减少查询过程中需要处理的数据量，显著提升查询速度。

2. Firestore选择Index Alpha或Index Beta的场景 #

Firestore查询优化器会根据查询的过滤条件、排序需求及索引结构，选择成本最低的索引：

优先选择Index Beta的场景 #

• 当查询是仅包含fieldA、fieldB、fieldC的等值过滤（即当前查询结构）时，优化器会优先选Index Beta——它的前缀字段基数更高，能最快缩小结果集，查询成本更低。
• 如果查询包含基于fieldA的排序（比如.orderBy('fieldA')），Index Beta的前缀正好匹配排序字段，会被优先选中（Firestore要求排序字段必须是索引前缀）。

优先选择Index Alpha的场景 #

• 当查询包含基于fieldC的排序需求（比如.orderBy('fieldC')）时，Index Alpha的前缀是fieldC，正好匹配排序字段，会被优先选择。
• 如果查询的过滤逻辑调整为优先依赖fieldC和fieldB的过滤（比如仅过滤fieldC+fieldB，再追加fieldA过滤），且无排序需求时，优化器可能会选择更匹配过滤顺序的Index Alpha，但这种场景下性能依然不如Index Beta。

若两个索引都能满足查询需求，优化器会自动评估哪个索引处理的数据量更少，最终选择效率更高的那个。

内容的提问来源于stack exchange，提问作者llamington