MongoDB 的 $lookup 是什么？什么时候应该反范式而不是 Join？

简化版

$lookup 是 MongoDB 聚合管道里的关联查询能力，类似左外连接。但 MongoDB 建模更强调按访问模式组织数据，高频读取常常应通过嵌入和冗余来避免频繁 Join。

详细版

MongoDB 支持用 $lookup 在聚合管道中关联另一个集合，适合低频后台查询、数据补全、报表类场景。

$lookup 默认更像 left outer join，会把匹配结果放进数组字段。
数据量大、关联字段无索引、管道复杂时，$lookup 成本会很高。
MongoDB 的建模原则是围绕查询场景设计文档，不是照搬关系型三范式。
一对少、强绑定、一起读取的数据，通常适合嵌入；一对多很大、独立生命周期强的数据，适合引用。
高频接口若每次都 $lookup，要考虑反范式冗余、预聚合或读模型。

完整版教学

一、为什么 MongoDB 也需要关联查询

虽然 MongoDB 是文档数据库，但真实业务仍然有用户、订单、商品、评论这些实体关系。完全不关联是不现实的，所以 MongoDB 提供 $lookup，让一个集合可以在聚合管道中查询另一个集合并合并结果。问题在于，能关联不代表应该把关系型数据库的 Join 思维原封不动搬过来。MongoDB 的文档模型更适合把“一次请求要一起读的数据”放得更近，从而减少运行时关联成本。

db.orders.aggregate([
  {
    $lookup: {
      from: "users",
      localField: "userId",
      foreignField: "_id",
      as: "user"
    }
  }
])

记忆钩子：$lookup 是补工具，不是建模免死金牌；MongoDB 先问“怎么读”，再问“怎么关联”。

二、`$lookup` 的结果为什么是数组

$lookup 把匹配到的外部集合文档放入 as 指定的数组字段里。即使你认为是一对一关系，结果也仍是数组，因为数据库层面匹配结果可能是 0 条、1 条或多条。如果后续确实要按单对象处理，通常还会配合 $unwind。理解这个数组语义很重要，否则应用层拿到数据后会把 user.name 写错，实际应该处理 user[0].name 或先展开。

db.orders.aggregate([
  { $lookup: { from: "users", localField: "userId", foreignField: "_id", as: "users" } },
  { $unwind: { path: "$users", preserveNullAndEmptyArrays: true } }
])

三、性能关键：关联字段和数据规模

$lookup 的性能首先看外部集合的关联字段是否有合适索引。比如订单按 userId 关联用户 _id，用户 _id 天然有索引，成本相对可控；如果按一个没有索引的字段关联，外部集合可能被反复扫描。其次看主集合输入规模，如果前面没有 $match 先缩小订单范围，拿 100 万订单去关联用户，成本自然高。聚合管道里常见优化是先过滤、再关联、再投影。

较好的顺序：
$match 缩小订单到 1000 条
-> $lookup 关联用户
-> $project 只保留必要字段

较差的顺序：
全量 100 万订单先 $lookup
-> 再过滤

四、反范式为什么是 MongoDB 的常见答案

关系型设计强调减少冗余，MongoDB 设计更强调读路径效率。比如订单列表页每次都展示用户名和用户头像，如果这些信息变化不频繁，可以在订单里冗余 userSnapshot。这样查询订单列表时不需要每次 $lookup 用户集合。冗余的代价是更新复杂：用户改头像后，历史订单是否需要同步？如果不需要，同步成本就省掉了；如果需要，就要设计异步修正或读模型重建。

数据关系	更适合	原因
一对少、一起读	嵌入	单文档读取快
一对多且无限增长	引用	避免文档过大
高频展示少量外部字段	冗余快照	减少 Join
后台低频统计	`$lookup`	开发灵活

五、带数字比较 Join 与冗余

假设订单列表接口 QPS 200，每次返回 20 个订单。如果每个订单都要关联用户，理论上每秒涉及 4000 个订单到用户的匹配动作。即使索引很好，这也是持续的数据库压力。如果订单里冗余了用户名和头像，接口只查订单集合即可。代价是用户改名时历史订单是否同步，但很多订单快照业务本来就应该保留当时状态，例如下单时的收货地址、商品标题和价格。

{
  _id: ObjectId("..."),
  userId: ObjectId("..."),
  userSnapshot: {
    name: "小明",
    avatar: "https://example.com/a.png"
  },
  totalAmount: 199
}

六、什么时候 `$lookup` 仍然合理

不要把反范式理解成完全不用 $lookup。后台管理、低频报表、数据校验、临时分析、迁移脚本，使用 $lookup 很合理，因为开发效率更重要，性能压力也可控。还有一些数据确实独立生命周期很强，强行嵌入会导致更新和一致性更麻烦。真正的判断标准是访问频率、结果规模、更新频率和一致性要求，而不是教条地“MongoDB 不能 Join”。

db.orders.aggregate([
  { $match: { createdAt: { $gte: ISODate("2026-01-01") } } },
  { $lookup: { from: "coupons", localField: "couponId", foreignField: "_id", as: "coupon" } },
  { $project: { totalAmount: 1, coupon: { $slice: ["$coupon", 1] } } }
])

七、常见误区与追问

误区：MongoDB 不能做 Join。 它有 $lookup，只是建模不鼓励把高频核心读路径都设计成运行时 Join。
误区：有 $lookup 就不用反范式。 高频接口的关联成本会持续放大，冗余读模型常常更稳。
误区：冗余一定是坏设计。 文档数据库里受控冗余是用写入复杂度换读取性能的常见策略。
追问：$lookup 为什么返回数组？ 因为匹配结果可能是 0、1、多条，MongoDB 用数组统一表达。
追问：如何优化 $lookup？ 先 $match 缩小输入，确保关联字段有索引，只投影必要字段，必要时改成冗余模型。

八、加强记忆

这题可以用“读路径优先”来串：MongoDB 有 $lookup，但文档建模的核心是让一次请求需要的数据尽量在一个文档或一个读模型里拿到。低频、后台、分析场景可以 Join；高频、固定展示字段更适合嵌入、快照和冗余。回答时别极端地说不能 Join，也别把 $lookup 当万能，讲出取舍才是重点。

简化版

详细版