$lookup性能优化需四步：一、被关联集合foreignField必须建索引；二、$match必须置于$lookup前过滤主集合；三、用pipeline式$lookup减少数据搬运；四、确保关联字段类型一致。
被关联集合的 foreignField 必须建索引，否则 $lookup 会全表扫描
这是最常被忽略、也最容易验证的一点。$lookup 不会自动利用索引——它只在你显式创建了对应索引后，才可能加速匹配过程。如果 from 集合（即被关联集合）的 foreignField 没有索引，MongoDB 就得对每一条主文档，在整个目标集合里逐条比对字段值，I/O 和 CPU 开销陡增。
- 用
db.collection.getIndexes()确认目标集合上是否存在{ foreignField: 1 }或更优的复合索引 - 建索引命令示例：
db.products.createIndex({ _id: 1 })（若foreignField是_id）或db.orders.createIndex({ user_id: 1 }) - 注意：索引方向（
1或-1）对等值查询无影响，但若后续还带排序，需一并考虑 - 分片集群中，该索引必须是分片键前缀或包含分片键，否则路由层无法下推过滤
$lookup 前不加 $match，主集合输入集过大，再好的索引也救不了
索引只能加速“从一堆文档里找匹配项”，但如果主集合本身没过滤，$lookup 会为成千上万条文档都发起一次子查询——即使每条子查询都走索引，总耗时和内存占用仍会爆炸。
- 错误写法：
db.users.aggregate([ { $lookup: { from: "orders", localField: "_id", foreignField: "user_id", as: "orders" } }, { $match: { status: "active" } } ])——$match在$lookup后，索引无法减少主集合输入量 - 正确顺序：
$match必须放在$lookup之前，且条件字段最好已建索引（如db.users.createIndex({ status: 1 })） - 如果主集合文档平均关联上千条记录，聚合管道极易触发
"Exceeded memory limit for $group"错误
用 pipeline 形式的 $lookup 替代基础写法，避免拉回冗余字段
基础 $lookup 默认把整个匹配文档都加载进来，哪怕你只需要 name 和 status。网络传输、内存解码、后续 $unwind 全部因此变慢。
- 改用 pipeline 写法，把过滤和投影压到右集合侧：
{ $lookup: { from: "products", localField: "product_id", foreignField: "_id", as: "product", pipeline: [ { $match: { is_deleted: false } }, { $project: { name: 1, price: 1, _id: 0 } } ] } } - 这样 MongoDB 会在右集合内部先过滤、再裁剪字段，大幅降低数据搬运量
- 注意：pipeline 中不能引用左集合字段（除非配合
let+$$变量），且 MongoDB 5.0+ 才支持$lookup内使用$expr
关联字段类型不一致，索引完全失效，$lookup 直接静默不匹配
这是线上最隐蔽的性能坑之一：表面看语句没错、索引也建了，但 $lookup 结果为空或极低，explain 显示 totalDocsExamined 高得离谱。大概率是 ObjectId 和字符串 ID 混用。
- 检查两边字段真实类型：
db.users.findOne().user_id和db.orders.findOne().user_id，用typeof或$type聚合判断 - 常见场景：用户 ID 存的是
ObjectId，但订单里存成了字符串"507f1f77bcf86cd799439011"—— 类型不同，索引和等值匹配全部失效 - 修复方式：统一类型（推荐全用
ObjectId），或建文本索引 +$toString（仅限 MongoDB 5.0+，且性能略降）
真正卡住的往往不是单点，而是多个条件叠加：没索引 + 主集合未过滤 + 拉全量文档 + 类型错位。调优时得一个个排除，别指望加个索引就万事大吉。
