Firestore含OR操作的查询超时问题求助

问题根源拆解 #

• OR运算符触发的多查询合并开销
  Firestore的Filter.or会将你的原查询拆分为两个独立子查询：

  1. myId == 123 AND createdAt <= 当前时间 AND deletedAt >= 当前时间
  2. myId == 123 AND createdAt <= 当前时间 AND deletedAt == null
     即使已创建对应索引，Firestore需要分别执行这两个子查询，再将结果在内存中按createdAt DESC排序、去重后取前500条。当myId=123下的文档量达27k时，每个子查询可能需要扫描大量符合myId条件的文档，再过滤时间条件，整体扫描量远超预期，触发超时。

• 索引匹配效率不足
  从explain结果的索引来看，字段顺序并非最优：

  • 第一个索引(myId ASC, createdAt DESC, deletedAt DESC, __name__ DESC)：针对子查询1，deletedAt的DESC排序与查询条件>=的匹配逻辑，会导致扫描范围更大，无法快速定位到符合deletedAt >= 当前时间的起始点。
  • 第二个索引(myId ASC, deletedAt ASC, createdAt DESC, __name__ DESC)：子查询2需要匹配deletedAt == null，虽然ASC索引会将null值排在最前，但后续还要过滤createdAt <= 当前时间，需要在null分组内扫描大量文档，当该分组数据占比过高时效率极低。

• 数据分布放大查询压力
  如果myId=123下的文档几乎都满足createdAt <= 当前时间，且deletedAt >= 当前时间或deletedAt == null的文档占比极高，两个子查询几乎要扫描全部27k文档，再做内存排序合并，这会极大消耗Firestore的查询资源，最终触发超时。

优化方案 #

• 重构查询逻辑，移除OR运算符
  新增一个派生字段（如isActive），在文档创建或更新时自动维护：当deletedAt == null或deletedAt >= 当前时间时设为true，否则设为false。重构后的查询无需OR，能直接利用单一复合索引快速定位：

  .where('myId', '==', 123)
  .where('createdAt', '<=', new Date())
  .where('isActive', '==', true)
  .orderBy('createdAt', 'desc')
  .limit(500)
  

  只需创建复合索引(myId ASC, createdAt DESC, isActive ASC)即可，查询效率会大幅提升。

• 针对性优化索引字段顺序
  若无法修改数据结构，为两个子查询分别创建更匹配的索引：

  • 针对子查询1：创建索引(myId ASC, deletedAt ASC, createdAt DESC)，deletedAt ASC能快速定位>= 当前时间的起始位置，再按createdAt过滤排序。
  • 针对子查询2：创建索引(myId ASC, createdAt DESC, deletedAt ASC)，先按createdAt过滤出符合时间条件的文档，再匹配deletedAt == null，减少扫描范围。

• 分批查询降低单次扫描量
  保留原查询逻辑的前提下，将查询按createdAt分段（比如每次查询最近7天、30天的数据），逐步获取结果并在客户端合并，减少单次查询需要扫描的文档数量，避免超时。

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