MongoDB聚合管道索引优化

MongoDB的聚合管道用起来顺手，但一旦数据量上来，动不动就扫全表、内存爆满、查询超时，根源十有八九出在索引没对齐管道操作。很多人以为给$match里的字段建个单字段索引就万事大吉，实际上聚合管道的索引利用逻辑比简单查询复杂得多。管道是分阶段执行的，索引只在管道开头能直接命中，后续阶段处理的是中间结果集，已经脱离原始集合的索引范围。这意味着你必须把最关键的过滤和排序逻辑尽可能往管道前段推，并且让索引覆盖这些操作。

先看一个最常见的性能陷阱。假设你有一个订单集合，聚合管道长这样：先$match过滤状态，然后$group按用户ID分组统计金额，最后$sort按总金额降序排列。新手通常只给status字段建索引，结果发现$group和$sort阶段仍然慢。问题在于$group需要处理所有匹配文档，$sort还要对分组结果排序，这两个操作都无法利用status上的索引。正确的做法是分析整个管道，找出哪些阶段可以合并到$match里提前过滤，以及是否可以通过复合索引同时覆盖过滤和排序需求。

MongoDB的查询优化器只在管道的第一阶段尝试使用索引，前提是该阶段是$match、$sort、$geoNear或$graphLookup这类可以直接映射到集合扫描的操作。如果第一个阶段是$match，优化器会分析查询条件，尝试匹配索引。这里有个关键细节：$match必须直接使用集合字段，不能包含对字段的表达式计算、$where操作符或对其他阶段生成字段的引用。比如{$match: {createdDate: {$gte: ISODate("2024-01-01")}}}能走索引，但{$match: {$expr: {$gt: ["$createdDate", "$$startDate"]}}}就走不了，因为$expr引入了变量和表达式。

复合索引的字段顺序在聚合场景下比普通查询更讲究。如果你的$match同时过滤status和createdDate，然后$sort按createdDate排序，那么索引{status: 1, createdDate: 1}能同时满足过滤和排序，避免内存排序。但如果$sort按amount排序，这个索引就帮不上忙，排序只能在内存里做。很多人忽略的一点是，$sort阶段即使不在管道开头，只要它紧跟在$match之后且排序字段包含在索引中，优化器也可能把$sort的操作提前到索引扫描阶段完成。前提是中间没有$unwind、$group、$project这类改变文档结构的阶段。

$lookup是聚合管道里最耗资源的操作之一，相当于在另一个集合上执行查询。很多人只关注主集合的索引，完全忽略被关联集合的索引，结果一个$lookup拖垮整个管道。$lookup的localField和foreignField必须在外键集合上有索引，这是铁律。如果你用的是带pipeline的$lookup语法，内层管道同样遵循索引规则，可以在内层$match上利用索引。

举个例子，订单集合关联用户集合获取用户信息，foreignField是userId，那用户集合的userId字段必须有索引。如果内层管道还加了{$match: {status: "active"}}过滤活跃用户，那{userId: 1, status: 1}的复合索引效果更好。另外要注意$lookup的执行方式，MongoDB 5.0之后对等值关联做了优化，但多对多关联仍然会产生大量中间结果。如果你只需要关联后的少量字段，用$project提前裁剪主集合的文档，减少传递到$lookup的数据量，间接降低关联开销。

覆盖索引的概念在聚合管道中同样适用，但实现条件更苛刻。当$match和$project（或者管道的输出字段）都完全被一个索引覆盖时，MongoDB可以直接从索引返回结果，连文档本身都不用读。这要求索引包含查询条件字段和返回字段。比如管道是$match按status过滤，然后$project只输出userId和amount，那么索引{status: 1, userId: 1, amount: 1}就能实现覆盖查询。执行计划里会显示"indexOnly": true，说明没有FETCH阶段。

实际操作中，覆盖索引对聚合管道的限制比较多。一旦管道里有$group、$lookup、$unwind这些改变文档形态的阶段，覆盖索引的优势就断了。所以覆盖索引最适合那些纯过滤加字段筛选的轻量管道，比如报表接口只需要统计计数或拉取少量字段的场景。建索引时要权衡索引大小和维护成本，别为了覆盖查询建一个包含七八个字段的巨型索引，写入性能会严重下降。

MongoDB官方的ESR规则（Equality, Sort, Range）在聚合管道索引设计中依然是黄金准则。$match里的等值条件字段放在索引最前面，然后是排序字段，最后是范围查询字段。比如管道先$match过滤{status: "completed", createdDate: {$gte: startDate}}，然后$sort按createdDate升序，索引{status: 1, createdDate: 1}完全符合ESR规则。但如果$sort按totalAmount排序，索引就变成{status: 1, totalAmount: 1}，createdDate的范围查询放最后。

有个容易被忽略的细节：$match里多个条件之间的执行顺序。MongoDB的优化器会根据索引自动重排$match条件，但仅限于同一层级。如果你的$match用了$and显式组合多个条件，优化器可以分别评估每个子句的索引适用性。但$or条件就麻烦得多，每个$or分支都需要单独的索引支持，否则整个$or可能退化为全表扫描。遇到$or查询，考虑拆成多个聚合查询然后用$unionWith合并结果，或者重新设计数据模型把$or条件转成等值查询。

$facet允许在一个管道里并行执行多个子管道，常用于仪表盘同时输出多个统计指标。但$facet有个致命弱点：所有子管道共享同一个输入文档流，索引只能在$facet之前利用。一旦进入$facet，每个子管道独立处理相同的中间结果，无法再回头用原始集合的索引。如果你的$facet子管道各自有不同的过滤条件，这些条件应该尽可能提取到$facet之前的$match阶段，用一个大而全的$match统一过滤，再让各子管道基于过滤后的结果做分组统计。

举个例子，电商后台需要同时统计不同状态订单的金额分布。与其在每个$facet子管道里写{$match: {status: "paid"}}、{$match: {status: "shipped"}}，不如在前面统一{$match: {status: {$in: ["paid", "shipped"]}}}，然后子管道用$group按status分组。这样索引只需要覆盖status字段，查询效率大幅提升。如果各子管道的过滤条件差异太大无法合并，那就要考虑是否真的需要$facet，换成多个独立的聚合查询分别走各自的索引，反而可能更快。

聚合管道默认有100MB的内存限制，超过就会报错。很多人第一反应是加{allowDiskUse: true}让操作溢写到磁盘，但这是治标不治本。磁盘溢写比内存操作慢几个数量级，正确的思路是通过索引减少进入管道的数据量。$match放在管道最前面，用高选择性索引把数据量降到内存可处理范围内。如果$group或$sort实在处理的数据量太大，考虑给这些阶段前面的$project瘦身，只保留必要字段，减少单文档大小。

还有一个进阶技巧：利用索引的局部性优化$sort。如果你的管道必须对大量数据排序，确保排序字段有索引，并且索引顺序与$sort一致。MongoDB可以利用索引的有序性直接输出排序结果，完全跳过内存排序步骤。执行计划里看到"SORT"阶段但"totalDocsExamined"为0，说明排序完全由索引完成。这对分页场景尤其重要，配合$skip和$limit可以做到索引级别的快速翻页，而不是每次翻页都重新排序全部数据。

设计索引不能靠猜，必须看执行计划。聚合管道用explain()方法，参数传"executionStats"获取详细统计。重点关注几个指标：totalDocsExamined和totalKeysExamined的比值，如果两者接近说明索引过滤效果好，如果totalDocsExamined远大于totalKeysExamined说明很多文档被扫描后丢弃，索引选择性不够。还有executionTimeMillis和memoryUsage，如果内存使用接近100MB红线，说明管道需要优化或拆分。

执行计划里的stage树能直观展示管道各阶段的执行方式。看到"COLLSCAN"就是全表扫描，必须消除。"IXSCAN"是索引扫描，理想状态。"FETCH"说明索引扫描后还要回表取文档，如果FETCH数量很大，考虑覆盖索引。"SORT"在内存里排序，如果排序数据量大，检查索引能否覆盖排序。"HASH_AGG"和"MERGE"是分组聚合的中间阶段，出现这些说明$group在正常工作，但要关注处理的数据量。

索引优化是个持续过程，数据分布会变，查询模式会变，索引也要跟着调整。定期跑慢查询日志，分析聚合管道的执行计划，删除未使用的索引，合并功能重叠的索引。一个集合上的索引数量控制在5个以内比较健康，太多索引拖累写入性能，太少索引拖累查询性能，这个平衡点需要根据业务读写比例来定。聚合管道的索引优化本质上是对数据流转路径的优化，理解每个阶段的数据变化，才能把索引建在刀刃上。