MongoDB v7.0.11中$search聚合致后续阶段性能骤降原因排查

现象重现 #

测试环境为包含10万条如下结构文档的集合：

{
  "_id": "1",
  "description": "Lorem Ipsum",
  "creator": "UserA"
}

仅创建基础Atlas Search索引：

{
  "mappings": { "dynamic": true }
}

不同聚合管道的执行时间差异显著：

• 单独$search：约100ms

  [
    {
      "$search": {
        "wildcard": {
          "query": "*b*",
          "path": { "wildcard": "*" },
          "allowAnalyzedField": true
        }
      }
    }
  ]
  

• $search + $match（无匹配结果）：约25秒

  [
    {
      "$search": {
        "wildcard": {
          "query": "*b*",
          "path": { "wildcard": "*" },
          "allowAnalyzedField": true
        }
      }
    },
    { "$match": { "creator": null } },
    { "$limit": 100 }
  ]
  

• 单独$match：约100ms

  [
    { "$match": { "creator": null } },
    { "$limit": 100 }
  ]
  

• $set + $match：约200ms（强制$match在管道中执行）

  [
    {
      "$set": {
        "creator": { "$concat": ["$creator", "ABC"] }
      }
    },
    { "$match": { "creator": null } },
    { "$limit": 100 }
  ]
  

替换$match为$sort也存在类似性能差距。

核心分析 #

这种极端性能差异的核心矛盾在于：同样是处理全量10万条文档，单独执行$match仅需100ms，而$search之后执行$match却耗时25秒，且explain输出差异极小。可能的原因包括：

1. 跨集群数据传输与处理开销
   Atlas Search是独立于MongoDB集群的服务，$search的结果需要从Search集群传输到MongoDB集群后再执行后续阶段。当$search返回全量文档时，数据传输的序列化/反序列化开销被放大，尤其是返回所有字段时。而单独$match直接在MongoDB集群本地扫描集合，无需跨集群数据传输。

2. 执行计划优化差异
   单独$match阶段可能利用了MongoDB的全表扫描优化（如快速终止逻辑、内存高效处理），但当$match跟在$search之后时，MongoDB可能未对来自Search的结果集应用相同优化策略，导致逐条低效处理。

3. 潜在的优化不足或bug
   这种量级的性能差距不符合预期，尤其是$set+$match仅需200ms的对比下，说明$search后的$match阶段存在未被优化的路径。explain输出无法体现实际执行中的底层差异，可能是优化器未正确识别后续阶段的处理需求。

可行的排查与优化方向 #

1. 限制$search返回的字段
   在$search中添加returnStoredSource: false，仅返回_id，后续通过$lookup获取所需字段再执行$match，减少跨集群传输的数据量：

   [
     {
       "$search": {
         "wildcard": {
           "query": "*b*",
           "path": { "wildcard": "*" },
           "allowAnalyzedField": true
         },
         "returnStoredSource": false
       }
     },
     { "$lookup": { "from": "your-collection", "localField": "_id", "foreignField": "_id", "as": "doc" } },
     { "$unwind": "$doc" },
     { "$match": { "doc.creator": null } },
     { "$limit": 100 }
   ]
   

2. 为过滤字段创建普通MongoDB索引
   给creator字段创建普通B树索引，观察$search后的$match是否能利用该索引加速过滤，避免全量结果集的逐条扫描。

3. 提交官方支持工单
   由于这种性能差异远超预期，且explain无法定位问题，建议向MongoDB官方提交支持工单，提供以下信息：

   • 完整的集合结构、索引定义
   • 各管道的explain详细输出（包括executionStats）
   • 性能测试的具体环境（Atlas集群规格、版本等）
   • 测试数据的代表性样本

内容的提问来源于stack exchange，提问作者Jean-Samuel Girard