聚合管道优化

$project 阶段放置

您使用 $project 阶段时，它通常应该是管道的最后一个阶段，用于指定要返回给客户端的字段。

在管道的开头或中间使用 $project 阶段来减少传递到后续管道阶段的字段数量不太可能提高性能，因为数据库会自动执行此优化。

（$project 或$unset 或$addFields 或$set ）+$match 序列优化

如果聚合管道包含投影阶段 ($addFields、$project、$set 或$unset），且其后跟随 $match 阶段，MongoDB 会将 $match 阶段中无需使用投影阶段计算的值的所有过滤器移动到投影前的新的 $match 阶段。

如果聚合管道包含多个投影或 $match 阶段，MongoDB 会对每个 $match 阶段执行此优化，将每个 $match 过滤器移到过滤器不依赖的所有投影阶段之前。

考虑包含以下阶段的管道示例：

{
   $addFields: {
      maxTime: { $max: "$times" },
      minTime: { $min: "$times" }
   }
},
{
   $project: {
      _id: 1,
      name: 1,
      times: 1,
      maxTime: 1,
      minTime: 1,
      avgTime: { $avg: ["$maxTime", "$minTime"] }
   }
},
{
   $match: {
      name: "Joe Schmoe",
      maxTime: { $lt: 20 },
      minTime: { $gt: 5 },
      avgTime: { $gt: 7 }
   }
}

优化器会将 $match 阶段分解为四个单独的过滤器，每个过滤器对应 $match 查询文档中的一个键。然后，优化器会将每个过滤器移至尽可能多的投影阶段之前，从而按需创建新的 $match 阶段。

在此示例中，优化器将自动生成以下优化后的管道：

{ $match: { name: "Joe Schmoe" } },
{ $addFields: {
    maxTime: { $max: "$times" },
    minTime: { $min: "$times" }
} },
{ $match: { maxTime: { $lt: 20 }, minTime: { $gt: 5 } } },
{ $project: {
    _id: 1, name: 1, times: 1, maxTime: 1, minTime: 1,
    avgTime: { $avg: ["$maxTime", "$minTime"] }
} },
{ $match: { avgTime: { $gt: 7 } } }

$match 筛选器 { avgTime: { $gt: 7 } } 依赖 $project 阶段来计算 avgTime 字段。$project 阶段是该管道中的最后一个投影阶段，因此 avgTime 上的 $match 筛选器无法移动。

maxTime 和 minTime 字段在 $addFields 阶段计算，但不依赖 $project 阶段。优化器已为这些字段上的筛选器创建一个新的 $match 阶段，并将其置于 $project 阶段之前。

$match 筛选器 { name: "Joe Schmoe" } 不使用在 $project 或 $addFields 阶段计算的任何值，因此它在这两个投影阶段之前移到了新的 $match 阶段。

优化后，筛选器 { name: "Joe Schmoe" } 在管道开始时会处于 $match 阶段。此举还允许聚合在最初查询该集合时使用针对 name 字段的索引。

$sort +$match 序列优化

当序列中的 $sort 后面是 $match 时，$match 会在 $sort 之前移动，以最大限度地减少要排序的对象数量。例如，如果管道由以下阶段组成：

{ $sort: { age : -1 } },
{ $match: { status: 'A' } }

在优化阶段，优化器会将序列转换为以下内容：

{ $match: { status: 'A' } },
{ $sort: { age : -1 } }

$redact +$match 序列优化

如果可能，当管道有 $redact 阶段紧接着 $match 阶段时，聚合有时可以在$redact阶段之前添加$match阶段的一部分。如果添加的 $match 阶段位于管道的开头，则聚合可以使用索引并查询集合以限制进入管道的文档数量。有关更多信息，请参阅使用索引和文档过滤器提高性能。

例如，如果管道由以下阶段组成：

{ $redact: { $cond: { if: { $eq: [ "$level", 5 ] }, then: "$$PRUNE", else: "$$DESCEND" } } },
{ $match: { year: 2014, category: { $ne: "Z" } } }

优化器可以在 $redact 阶段之前添加相同的 $match 阶段：

{ $match: { year: 2014 } },
{ $redact: { $cond: { if: { $eq: [ "$level", 5 ] }, then: "$$PRUNE", else: "$$DESCEND" } } },
{ $match: { year: 2014, category: { $ne: "Z" } } }

$project/$unset +$skip 序列优化

如果序列中的 $project 或 $unset 后面是 $skip，则 $skip 在 $project 之前移动。例如，如果管道由以下阶段组成：

{ $sort: { age : -1 } },
{ $project: { status: 1, name: 1 } },
{ $skip: 5 }

在优化阶段，优化器会将序列转换为以下内容：

{ $sort: { age : -1 } },
{ $skip: 5 },
{ $project: { status: 1, name: 1 } }

$sort +$limit 合并

当 $sort 在 $limit 之前时，, the optimizer can coalesce the into the如果没有干预阶段（例如 $unwind、$group）修改文档的数量，则优化器可以将 $limit 阶段合并到 $sort。如果有管道阶段更改了 $sort 和 $limit 阶段之间的文档数量，则 MongoDB 不会将 $limit 合并到 $sort 中。

例如，如果管道由以下阶段组成：

{ $sort : { age : -1 } },
{ $project : { age : 1, status : 1, name : 1 } },
{ $limit: 5 }

在优化阶段，优化器会将此序列合并为以下内容：

{
    "$sort" : {
       "sortKey" : {
          "age" : -1
       },
       "limit" : NumberLong(5)
    }
},
{ "$project" : {
         "age" : 1,
         "status" : 1,
         "name" : 1
  }
}

此操作可让排序操作在推进时仅维护前 n 个结果，其中 n 为指定的限制，而 MongoDB 仅需要在内存中存储 n 个项目[1]。有关更多信息，请参阅 $sort 操作符和内存。

$limit +$limit 合并

当 $limit 紧随另一个 $limit 时，这两个阶段可以合并为一个 $limit，以两个初始限额中较小的为合并后的限额。例如，一个管道包含以下序列：

{ $limit: 100 },
{ $limit: 10 }

然后第二个 $limit 阶段可以合并到第一个 $limit 阶段，形成一个 $limit 阶段，新阶段的限额 10 是两个初始限额 100 和 10 中的较小者。

{ $limit: 10 }

$skip +$skip 合并

当 $skip 紧随在另一个 $skip 之后时，这两个阶段可以合并为一个 $skip，其中的跳过数量是两个初始跳过数量的总和。例如，一个管道包含以下序列：

{ $skip: 5 },
{ $skip: 2 }

然后第二个 $skip 阶段可以合并到第一个 $skip 阶段，形成一个 $skip 阶段，新阶段的跳过数量 7 是两个初始限额 5 和 2 的总和。

{ $skip: 7 }

$match +$match 合并

当 $match 紧随另一个 $match 之后时，这两个阶段可以合并为一个 $match，用 $and 将条件组合在一起。例如，一个管道包含以下序列：

{ $match: { year: 2014 } },
{ $match: { status: "A" } }

然后第二个 $match 阶段可合并到第一个 $match 阶段并形成一个 $match 阶段

{ $match: { $and: [ { "year" : 2014 }, { "status" : "A" } ] } }

$lookup +$unwind 合并

当 $unwind 紧随另一个 $lookup，且 $unwind 在 $lookup 的 as 字段上运行时，优化器可以将 $unwind 合并到 $lookup 阶段。这样可以避免创建大型中间文档。

例如，一个管道包含以下序列：

{
  $lookup: {
    from: "otherCollection",
    as: "resultingArray",
    localField: "x",
    foreignField: "y"
  }
},
{ $unwind: "$resultingArray"}

优化器可以将 $unwind 阶段合并到 $lookup 阶段。如果您使用 explain 选项运行聚合，则 explain 输出将显示合并后的阶段：

{
  $lookup: {
    from: "otherCollection",
    as: "resultingArray",
    localField: "x",
    foreignField: "y",
    unwinding: { preserveNullAndEmptyArrays: false }
  }
}

索引

聚合管道可以使用输入集合中的索引来提高性能。 使用索引会限制阶段处理的文档数量。 理想情况下，索引可以覆盖阶段查询。 覆盖查询的性能特别高，因为索引会返回所有匹配的文档。

例如，由 $match、$sort、$group 组成的管道可以从每个阶段的索引中受益：

• $match查询字段上的索引可以有效地识别相关数据

• 排序字段上的索引可以按排序顺序返回$sort阶段的数据

• 与$sort顺序匹配的分组字段上的索引可以返回执行$group阶段（覆盖的查询）所需的所有字段值

要确定管道是否使用了索引，请查看查询计划并查找 IXSCAN 计划或 DISTINCT_SCAN 计划。

对于聚合管道的早期阶段，请考虑对查询字段建立索引。可以从索引受益的阶段是：

$match 阶段

如果$match是管道中的第一阶段，则在查询规划器进行任何优化之后，可以使用索引来筛选文档。

$sort 阶段

只要$sort前面没有$project 、 $unwind或$group阶段，就可以从索引中受益。

$group 阶段

$group 如果满足以下所有条件，则可以使用索引查找每组中的第一个文档：

• $sort阶段对$group之前的分组字段进行排序

• 存在与分组字段的排序顺序匹配的索引

• $first是$group阶段中唯一的累加器

请参阅 $group 性能优化，查看示例。

$geoNear 阶段

$geoNear始终使用索引，因为它必须是管道中的第一阶段并且需要地理空间索引。

此外，管道中的一些后期阶段在从其他未修改的集合中检索数据时，可以使用这些集合上的索引来实现优化。这些阶段包括：

• $lookup

• $graphLookup

• $unionWith

文档筛选器

如果聚合操作只需要集合中文档的子集，请先过滤文档：

• 使用 $match、$limit 和 $skip 阶段来限制进入管道的文档。

• 在可能的情况下，将 $match 放在管道的开头，以使用索引扫描集合中的匹配文档。

• 管道开头的 $match 后面跟上 $sort 等同于带有排序的单个查询，并且可以使用索引。

$sort +$skip +$limit 序列

管道的阶段序列为：首先为 $sort，其次为 $skip，再次为 $limit：

{ $sort: { age : -1 } },
{ $skip: 10 },
{ $limit: 5 }

优化器执行 $sort + $limit 合并以将此序列转换为以下内容：

{
   "$sort" : {
      "sortKey" : {
         "age" : -1
      },
      "limit" : NumberLong(15)
   }
},
{
   "$skip" : NumberLong(10)
}

重新排序后，MongoDB 增加了 $limit 的数量。