如何用MongoDB聚合管道提高数据查询效率的方法

先说说我在实际工作中经常遇到的几个典型场景：大多数 MongoDB 聚合查询性能低下的原因，往往不是写法的复杂程度，而是索引没有正确命中，或者管道的阶段顺序安排不当。与其凭直觉猜测，不如直接使用 explain("executionStats") 的输出结果，然后根据数据扫描量与内存占用这两个关键指标来精准调优。

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

不要等到用户投诉了才想起排查，每次修改聚合管道后，都应该顺手执行一次 explain 验证。这个命令不仅显示耗时，更能揭示真实的执行路径。以下是几个典型现象及其判断方法：

• 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 没开启却指望大数据量能稳定运行。这些细节如果不盯死，调整参数或更换硬件都很难根治问题。