最快方式是嵌入而非$lookup，仅当数据量大、更新频繁或关系复杂（如评论、物流、多对多标签）且无法满足嵌入约束时才用$lookup，并须确保localfield和foreignfield均有索引，否则将全表扫描。
最快的方式不是用 $lookup，而是根本不用它——把关联数据嵌入（embed）到主文档里。
什么时候该用 $lookup？
只有当你无法避免分离存储时才用。典型场景包括：
- 用户信息（
users）和评论（comments）：评论量极大，且需独立分页、按时间排序 - 订单（
orders）和物流轨迹（shipments）：轨迹更新频繁，每次写入都触发整个订单文档重写不现实 - 多对多关系，比如文章（
articles）和标签（tags）：一个文章有几十个标签，每个标签又被上千篇文章引用
这些情况下，硬塞进一个文档会导致写放大、更新冲突或突破 16MB 限制，$lookup 是合理选择——但必须配合索引和管道优化。
$lookup 性能卡点在哪？
最常被忽略的瓶颈是没在 localField 和 foreignField 上建索引。比如：
db.orders.createIndex({ "user_id": 1 })<br>db.users.createIndex({ "_id": 1 })
缺任意一个，$lookup 就会全表扫描外部集合。另外，如果后续立刻跟 $unwind，MongoDB 虽然会自动合并优化，但前提是 as 字段输出的是非空数组；若大量匹配结果为空（比如 user_id 在 users 中不存在），$unwind 仍会生成空文档，拖慢整体流程。
嵌入（Embed）比 $lookup 快多少？
实测中，同等硬件下，嵌入式查询耗时通常只有 $lookup 的 1/3～1/5。原因很直接：一次磁盘 I/O + 一次内存解析，而不是两次 I/O + 网络序列化 + 数组拼装。但要注意边界：
- 嵌入字段不能动态增长无上限（如日志列表、历史版本）
- 嵌入内容若高频更新（如用户头像 URL、收货地址），会引发主文档反复写入
- 嵌入后，单文档体积接近 2MB 时就要警惕——虽然没到 16MB 上限，但已影响复制延迟和 WiredTiger 压缩效率
真正难的不是选嵌入还是 $lookup，而是识别哪些字段“看起来可嵌入”，实际却因业务逻辑耦合而变成定时炸弹——比如订单里的用户昵称，看似静态，但用户改名后要不要同步更新所有历史订单？这个一致性成本，往往比一次 $lookup 高得多。
