如何通过MongoDB聚合管道提升数据查询效率？

先说我观察到的几个典型问题：大部分MongoDB聚合慢，真不是写法出了多复杂的错，八成是索引没生效，或者阶段顺序反了。与其靠猜，不如直接看explain("executionStats")的结果，再根据数据扫描量和内存占用这两项关键指标来动刀。

用 explain("executionStats") 快速定位瓶颈

别等到用户投诉了才想起来查，每次改完聚合管道都应该顺手跑一遍。这个命令不只是告诉你耗时，更能暴露真实的执行路径。看几个典型现象：

• totalDocsExamined 远大于 nReturned，比如查回来200条却扫描了50万条 —— 这是过滤太晚或者索引没命中，第一时间检查第一个 $match 字段上有没有建索引。
• totalKeysExamined 接近 totalDocsExamined 但耗时依然高 —— 这反而说明索引其实已经生效了，问题出在管道阶段本身。比如 $unwind 之后文档数量爆炸，或者 $group 之前没有用 $project 精简字段。
• 某个 stage 下出现 "memUsage": 98765432 这种数字 —— 内存超限的风险已经很高了，该加 allowDiskUse: true。否则系统静默降级，越跑越慢。
• 看到 stage: "COLLSCAN" 出现在 $lookup 的 from 集合里 —— 问题不在主集合，而是关联的那个集合缺索引。

$match 必须放最前面，字段顺序也不能乱

索引只对聚合管道里「第一个能走索引的 $match」生效。如果后面再写 $match，数据已经变形了，索引基本就废了。这里有几个细节值得注意：

• 复合索引的字段顺序必须跟 $match 里的查询顺序一致。比如建了 db.logs.createIndex({userId: 1, createdAt: 1})，它能高效匹配 {$match: {userId: "u1", createdAt: {$gte: ...}}}；但如果查询写成 {$match: {createdAt: ..., userId: "u1"}}，效果就会差很多，甚至直接不走索引。
• 类型必须一致：索引是 ObjectId，查询却传了个字符串ID，索引直接跳过。
• $lookup 内部的 $match（pipeline 形式）也要单独建索引，而且得建在 from 集合上，不是主集合。

什么情况下必须加 allowDiskUse: true

不是等到内存不够了才开，而是只要管道里有 $group、$sort 或 $unwind，并且输入数据量不可控，那就应该默认打开。原因很简单：

• MongoDB 默认有100MB内存限制。一旦超限，$group 会自动尝试降级到磁盘，但不开 allowDiskUse 会直接报错，返回类似 errmsg: "Exceeded memory limit..." 的错误。
• 开了之后不会报错，但性能波动会很大——有时快有时慢，完全取决于磁盘I/O。所以必须配合 explain 来看是不是真的触发了磁盘落盘操作。
• 生产环境建议始终显式传 {allowDiskUse: true}，别依赖静默行为。

$project 不只是删字段，更是控内存的关键

很多人觉得 $project 就是选几个字段返回而已，其实它直接影响中间数据的体积和内存压力。几个要点：

• 在 $match 之后立刻加一个 $project，只保留后续阶段真正需要的字段。比如 $group 只用 userId 和 amount，那就只投这两个。
• 尽量避免在 $project 里做复杂的计算，比如 $concat、$dateToString。这些操作会在每条文档上执行，拖慢整个阶段。
• _id: 0 别省。尤其当 $group 后面接 $sort 的时候，多余的字段会跟着一起排序，徒增开销。

真正卡住性能的，常常不是某一行代码写得不对，而是 $match 没走索引、$unwind 之后没 $project、或者 allowDiskUse 没开却指望大数据量能稳如老狗。这些点不盯死，调参数、换硬件都很难解决问题。