$lookup慢且索引无效，是因为索引必须建在from集合的foreignfield上，且需满足字段名、类型、方向一致，数组字段、通配符索引或低版本mongodb均会导致索引失效。
为什么$lookup慢，但加了索引还是没用？
因为索引只对 foreignField 有效，且必须建在 from 指定的集合上——不是左表，不是 localField，而是右表的 foreignField 字段。很多同学在左表字段上建了索引，或者只建了单字段索引却忽略类型匹配，结果 $lookup 依然全表扫描。
- 用
db.otherCollection.getIndexes()确认索引是否真存在，且字段名、方向（1或-1）与foreignField完全一致 - 检查字段值类型：如果
localField是ObjectId，但foreignField存的是字符串（比如"507f1f77bcf86cd799439011"），索引完全不生效 - 分片集群下，索引还必须建在分片键上或包含分片键，否则路由层无法定位数据
foreignField 索引必须是单字段还是复合？
绝大多数情况下，单字段索引就够了——$lookup 的匹配逻辑本质就是等值查找 foreignField == localField 值，B-Tree 索引对单字段等值查询最高效。只有当你在 $lookup 的 pipeline 里额外加了 $match 过滤（比如只查状态为 active 的关联文档），才需要把过滤字段一起加入复合索引。
- 基础场景（无 pipeline 过滤）：
db.products.createIndex({ _id: 1 }) - 带 pipeline 过滤场景：
db.products.createIndex({ _id: 1, status: 1 })，配合{ $lookup: { from: "...", pipeline: [ { $match: { status: "active" } } ], ... } } - 别给
localField单独建索引——它不影响$lookup扫描右表的速度，只影响左表自身查询效率
如何验证索引真的被用了？
不能只看执行计划里有没有 “IXSCAN”，得看它扫了多少文档。用 .explain("executionStats") 查看 $lookup 阶段的 nReturned 和 totalDocsExamined：理想情况两者应接近；如果 totalDocsExamined 远大于 nReturned，说明索引未命中或字段类型不匹配。
- 示例命令：
db.orders.aggregate([ { $lookup: { from: "products", localField: "productId", foreignField: "_id", as: "p" } } ]).explain("executionStats") - 重点看输出中
stages[0].$lookup...executionStats.totalDocsExamined是否等于匹配数 - Robo 3T 的可视化执行计划里，
$lookup节点下方若显示 “Collection Scan” 而非 “Index Scan”，基本可断定索引失效
容易被忽略的三个硬性前提
即使索引语法、类型、位置全对，以下三点任一不满足，索引照样不参与 $lookup 匹配：
-
foreignField字段不能是数组（哪怕只存一个值），MongoDB 不支持对数组字段建等值索引用于$lookup - 集合不能启用了通配符模式（wildcard index），这种索引不支持
$lookup的精确匹配路径 - MongoDB 版本低于 3.6 时，
$lookup不支持 pipeline 参数，而旧版对索引的利用更弱，建议至少升级到 4.2+
$lookup 少扫几万行，但如果右表单次匹配返回几千个文档，后续 $unwind 或 $group 依然会卡住。真正压测时，得连同内存占用、网络传输量一起看。
