根本原因是$lookup默认将右表全部匹配结果加载内存做哈希连接；即使左表仅10条，右表关联出数万文档也会oom。
为什么 $lookup 一加条件就 OOM？
根本原因不是数据量大，而是 MongoDB 在执行 $lookup 时默认把整个右表（被关联集合）的匹配结果全加载进内存做哈希连接。哪怕只查 10 条左表数据，如果右表关联出几万文档，内存直接飙满。
典型现象：errmsg: "Sort exceeded memory limit of 104857600 bytes" 或进程被系统 kill —— 这说明聚合管道卡在 $lookup 后的 $sort/$group 阶段，但根子在 $lookup 没控制好中间结果集大小。
- 别指望加
.limit()在$lookup外面能省内存：它只限制最终输出，不减少关联过程的内存占用 -
$lookup的pipeline选项里用$limit有效，但仅当右表有索引支撑筛选时才真正降低扫描量 - 如果右表没在关联字段建索引，
$lookup会全表扫描，allowDiskUse也救不了——磁盘换不来性能，只会让慢查询更慢、更稳地失败
allowDiskUse: true 到底要不要开？
开，但必须配合其他约束，否则只是把内存溢出变成磁盘 I/O 爆炸和查询超时。
它只对聚合管道生效，且仅允许将临时排序、分组、去重等操作的数据写到磁盘（/tmp 或配置的 dbPath 下的 journal/_tmp），不改变 $lookup 本身的数据加载逻辑。
- 必须显式传参：
db.collection.aggregate([...], { allowDiskUse: true })，驱动里也要对应设置（如 Node.js 的options.allowDiskUse = true） - 确认 MongoDB 版本 ≥ 4.4：旧版本对
$lookup+allowDiskUse支持不稳定，尤其嵌套 pipeline 场景容易报"unrecognized field 'allowDiskUse'" - 检查磁盘空间和权限：
mongod进程必须对临时目录有读写权限，且剩余空间 > 预估中间结果大小 × 2
比 allowDiskUse 更关键的三件事
90% 的内存问题，靠这三项优化就能绕过磁盘缓存：
- 在右表的
foreignField上建索引：db.rightCollection.createIndex({ "status_id": 1 })—— 这让$lookup能走索引扫描，而非全表加载 - 用
pipeline选项提前过滤右表：{ from: "orders", let: { uid: "$user_id" }, pipeline: [ { $match: { $expr: { $eq: ["$user_id", "$$uid"] } } }, { $match: { status: "completed" } } ], as: "orders" }—— 注意两个$match的顺序：先$expr关联，再普通字段过滤，MongoDB 才能下推索引 - 控制返回字段：
$project紧跟在$lookup后，只保留需要的字段，例如{ _id: 0, amount: 1, created_at: 1 }—— 减少每条关联文档的内存 footprint
什么时候该考虑拆成两次查询？
当关联逻辑复杂（比如多级 $lookup、右表需聚合计算）、或右表数据天然稀疏（一个用户平均只对应 1–2 条订单），硬扛聚合反而更慢更易崩。
典型场景：users 查 100 个用户基本信息 → 提取所有 user_id → 一次 find({ user_id: { $in: [...] } }) 拉订单 → 应用层 merge。
- 网络往返增加，但避免了 MongoDB 单次聚合的内存峰值
- 应用层可做分页、缓存、降级（比如订单查不到就显示“暂无”）
- 注意
$in数组长度限制：MongoDB 默认 65536 个元素，超了要分批
真正棘手的永远不是磁盘开关开不开，而是没想清楚：这个关联，是不是非得在数据库里做完？
