MongoDB 自关联场景下查询关联指定属性被引用文档的实现优化方案

存在比原流程更简便高效的实现方案，可根据实际数据量、查询复杂度选择对应方案，整体能减少冗余聚合阶段，同时提升匹配的索引命中效率。

原实现的冗余开销来源 #

• 用$cond判断ref字段存在的写法，无法命中集合索引，还额外增加了条件运算的开销
• 将所有匹配条件都包裹在$expr中，完全放弃了索引命中的可能，导致关联阶段需要全表扫描被引用集合，数据量越大性能劣化越明显

分场景的最优实现 #

场景1：小数据量、高频查询 #

完全不需要使用聚合管道，拆成两次独立的索引查询即可，整体开销远低于聚合关联：

1. 先获取所有满足被引用文档属性条件的id列表

   // 例：获取所有toto="toto"的文档id，可命中toto字段的索引
   const validRefIds = db.haystack.distinct("id", { toto: "toto" })
   

2. 直接查询当前集合中ref字段命中有效id的条目

   // 可命中ref字段的索引，无额外临时字段处理
   db.haystack.find({ ref: { $in: validRefIds } })
   

场景2：大数据量、复杂关联逻辑 #

使用优化后的聚合管道，对比原实现减少冗余运算：

db.haystack.aggregate([
  // 1. 直接匹配带有效ref的文档，可命中ref字段的索引，替换原$cond判断逻辑
  { $match: { ref: { $exists: true, $ne: null } } },
  // 2. $lookup关联，拆分可走索引的匹配条件，减少扫描开销
  {
    $lookup: {
      from: "haystack",
      let: { refId: "$ref" },
      pipeline: [
        // 拆分普通匹配条件，可命中(id, toto)复合索引；剩余关联匹配保留$expr
        { $match: { 
          toto: "toto",
          $expr: { $eq: ["$id", "$$refId"] }
        } }
      ],
      as: "_ref"
    }
  },
  // 3. 筛选关联结果非空的条目
  { $match: { _ref: { $ne: [] } } },
  // 4. 清理临时关联字段，比project写法更简洁，无需手动声明保留原有字段
  { $unset: "_ref" }
])

优化后的聚合管道去掉了冗余的条件嵌套，匹配逻辑可最大化命中索引，临时字段清理的写法也比原实现更简洁。

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