MongoDB中localField式$lookup是否比pipeline式查询效率更高？

两种方案的核心差异 #

方案1：仅维护sharedWith数组 #

数据结构：

[
  {
    "_id": "1",
    "value": "value_of_1",
    "sharedWith": ["2"]
  },
  {
    "_id": "2",
    "value": "value_of_2",
    "sharedWith": []
  }
]

查询逻辑依赖表达式匹配：

db.mycollection.aggregate([
  { $match: { _id: "2" } },
  {
    "$lookup": {
      "from": "mycollection",
      let: { idVar: "$_id" },
      pipeline: [
        {
          $match: {
            $expr: { $in: ["$$idVar", "$sharedWith"] }
          }
        }
      ],
      "as": "sharedItems"
    }
  }
])

方案2：冗余维护sharedWith+gotSharedFrom数组 #

数据结构：

[
  {
    "_id": "1",
    "value": "value_of_1",
    "sharedWith": ["2"],
    "gotSharedFrom": []
  },
  {
    "_id": "2",
    "value": "value_of_2",
    "sharedWith": [],
    "gotSharedFrom": ["1"]
  }
]

查询逻辑简化为等值关联：

db.mycollection.aggregate([
  { $match: { _id: "2" } },
  {
    "$lookup": {
      "from": "mycollection",
      "localField": "gotSharedFrom",
      "foreignField": "_id",
      "as": "sharedItems"
    }
  }
])

读取效率与索引能力对比 #

读取效率提升：显著 #

方案1的$lookup依赖表达式匹配，MongoDB需要对sharedWith数组逐文档计算$in条件，即使sharedWith有索引，$expr的解析和计算开销也远高于方案2的等值关联。

方案2的关联是MongoDB优化最好的lookup场景：

• _id默认自带唯一主键索引，无需额外创建；
• 给gotSharedFrom创建多键索引后，MongoDB会直接通过索引定位关联文档，避免全集合扫描，数据量越大（如十万级以上文档），性能差距越明显，可能达到数倍甚至一个数量级。

索引支持：方案2更高效 #

• 方案1：仅能给sharedWith建多键索引，但$expr+$in无法充分利用索引的快速定位能力，本质是索引扫描后再做表达式校验；
• 方案2：gotSharedFrom的多键索引+_id的主键索引，会被查询优化器直接用于关联查询，属于最优的索引利用场景。

是否值得投入维护成本？ #

核心判断依据：读写比例 #

如果业务是读多写少（用户频繁查看项目及共享内容，共享/取消操作频率低），冗余维护的收益远大于成本：

• 维护成本可控：共享操作可通过多文档事务（MongoDB 8完全支持）保证两个字段的一致性，比如一次事务中同时更新两个文档的数组字段；
• 读取性能提升直接影响用户体验，高并发场景下收益更明显。

如果是写多读少（共享操作异常频繁），需权衡，但这类场景在共享业务中极少出现。

额外优化建议 #

1. 用$push+$pull原子操作更新数组，避免并发冲突；
2. 对高频查询的项目，可启用MongoDB 8的文档缓存特性，进一步降低读取延迟。

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