applicant与ticket集合关联聚合查询耗时过长，如何提升查询性能？

以下是针对当前慢查询的可落地优化方案：

• 索引优化（优先级最高）
  1. 针对applicant集合，为$match阶段用到的findApplicantCriteria所有字段建立复合索引，加速首阶段的申请人过滤效率，避免全表扫描19000条记录。
  2. 针对tickets集合，以「findCriteria过滤性最高的字段优先 + 关联申请人ID字段」的顺序建立复合索引，让$lookup子管道的$match阶段可以直接命中索引，无需遍历全量10000条ticket记录。如果使用MongoDB 5.0以上版本，可以建立覆盖索引，将子管道需要的所有字段都包含在索引中，避免回表查询进一步提速。
• 调整管道执行顺序，砍掉无效计算
  最终需求仅为统计符合条件的申请人总数，不需要返回申请人详情、也不需要获取全量关联的ticket数据，可以做以下改造：
  1. 删除$project阶段中name、phoneNumber、email、crn等无用字段的投影逻辑，减少数据处理和传输开销。
  2. $lookup子管道中新增$limit: 1配置，只要查到1条符合条件的ticket就终止查询，不需要拉取所有关联ticket，大幅降低数组构建和$size计算的开销，改造后的$lookup示例：

  {
    $lookup: {
      from: 'tickets',
      let: { applicant_id: '$_id' },
      pipeline: [
        { $match: { $expr: findCriteria } },
        { $limit: 1 } // 新增行，仅判断存在性即可
      ],
      as: 'tickets'
    }
  }
  

  3. 将tickets数量大于0的过滤逻辑提前到$lookup之后直接执行，不需要等待$project阶段处理后再过滤，进一步减少后续阶段的数据量。
• 改写查询逻辑，降低计算复杂度
  需求本质是统计「满足过滤条件、且至少有1条符合规则的关联ticket」的申请人总数，可以换更高效的逻辑实现：
  1. 先对tickets集合做聚合，过滤出符合findCriteria的记录，再对关联的申请人ID去重，拿到符合条件的申请人ID列表。
  2. 再对applicant集合做查询，过滤同时满足findApplicantCriteria、且_id在上述ID列表中的记录，直接统计数量即可，全程不需要关联操作，数据量小时效率提升尤为明显。
• 运行参数适配
  如果findApplicantCriteria过滤范围很大，需要处理全量申请人数据，可以在聚合请求中新增allowDiskUse: true配置，避免内存超限导致的查询卡顿或报错。如果是分片集群，建议将两个集合的分片键统一设置为申请人ID，让$lookup操作可以本地执行，无需跨节点拉取数据。

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