查询与聚合管道

2.1find 与查询操作符

find 按文档匹配条件返回文档集，投影裁剪字段；对应 SQL 的 WHERE + SELECT。

底层机制（比文档深一层）：filter 由比较操作符构成——$eq / $gt / $gte / $lt / $in，逻辑组合用 $and / $or。对标量字段这些操作符的语义和 SQL 一致。陷阱出现在数组字段：当一个字段是数组，{results: {$gt: 80, $lt: 90}} 的判定不是"存在一个元素同时满足两条件"，而是"数组里分别有元素满足 $gt: 80、分别有元素满足 $lt: 90"。所以 results: [95, 70] 会命中——因为 95 > 80 成立、70 < 90 成立，两个条件各被数组里不同的元素满足。要表达"同一个元素同时落在 (80, 90) 区间"，必须用 $elemMatch：{results: {$elemMatch: {$gt: 80, $lt: 90}}} 才会把 [95, 70] 排除掉。这是数组查询最常见的误解。

投影用 1 / 0 表达包含或排除：{title: 1} 只返回 title（外加默认带上的 _id），{body: 0} 返回除 body 外的全部字段。包含与排除不能在同一个投影里混用（_id 是唯一例外，允许 {title: 1, _id: 0} 这样显式排除主键）。

// 等值 + 范围 + IN，配投影只取需要的字段
db.students.find(
  { grade: "A", score: { $gte: 80, $lt: 90 }, city: { $in: ["SH", "BJ"] } },
  { name: 1, score: 1, _id: 0 }     // 只返回 name 和 score，排除 _id
)

// 数组字段的陷阱：results 是一个分数数组
// 这条会命中 results:[95,70]——95>80 与 70<90 分别由不同元素满足
db.exams.find({ results: { $gt: 80, $lt: 90 } })

// 要求"同一个元素"落在 (80,90)，必须用 $elemMatch——它会排除 [95,70]
db.exams.find({ results: { $elemMatch: { $gt: 80, $lt: 90 } } })

2.2聚合管道

聚合管道是一串有序 stage，每个 stage 把文档流变换后喂给下一个。

底层机制（比文档深一层）：管道是一个 stage 数组，文档流从第一个 stage 进、逐个 stage 流过、从最后一个 stage 出。核心 stage 各司其职：

• $match — 过滤文档，语义同 find 的 filter；尽量前置。
• $group — 按 _id 表达式分组，配累加器 $sum / $avg / $push（收集进数组）/ $addToSet（去重收集）。
• $project — 重塑字段：保留、重命名、计算派生值。
• $unwind — 把一个数组字段炸开成多条文档，数组里每个元素生成一条。
• $sort — 排序。
• $lookup — 对右集合做左外连接（§2.3 拆开它）。
• $facet — 一份输入并行跑多个子管道，各自独立产出。
• $bucket / $bucketAuto — 按边界把文档分桶，做直方图。

关键机制对照 SQL：SQL 是声明式的，写 WHERE / GROUP BY / ORDER BY 不规定执行顺序，由查询优化器决定怎么跑。管道是过程式的，stage 顺序由编写者显式写出，引擎原则上按写定的顺序执行——但优化器仍会做有限重排，最典型的是把 $match 向前下推到尽量靠前的位置，以减少后续 stage 需要处理的文档数。把 $match 和 $project 写在尽早的位置，等于亲手缩小下游每个 stage 的输入——这是管道性能的第一直觉。

// 已支付订单，按客户等级汇总总额，再按总额降序
db.orders.aggregate([
  { $match: { status: "paid" } },                    // 先过滤，缩小下游输入
  { $group: {
      _id: "$customer.tier",                          // 按嵌套字段分组
      revenue: { $sum: "$total" },                    // 累加订单金额
      orders:  { $sum: 1 }                            // 计数
  } },
  { $sort: { revenue: -1 } }                          // 总额从高到低
])

2.3$lookup 的真相：嵌套循环

$lookup 是对左侧每个输入文档去右集合查一次的嵌套循环，不是 hash / merge JOIN。

底层机制（比文档深一层）：对左侧管道流入的每一个文档，$lookup 取出 localField 的值，到右集合按 foreignField 查找匹配。这是一个嵌套循环：外层遍历左侧 N 个文档，内层每次去右集合查一遍。如果 foreignField 没有索引，内层每次查找都是一次右集合全扫描，整体复杂度 O(N × M)（N 是左侧文档数，M 是右集合大小）。对比关系型——优化器会按数据量和统计信息按代价选择 hash join 或 merge join，复杂度通常是 O(N + M) 量级，而不是乘积。

所以 $lookup 要快，只有三条路：(a) 给 foreignField 建索引，把内层每次全扫描降为索引查找；(b) 在 $lookup 之前用 $match 把左侧 N 缩小，直接砍掉外层循环次数；(c) 多数时候——回到 01 章那条主线（为访问模式建模），干脆把数据嵌入避免 JOIN。这正是为什么 MongoDB 的文档建模反复劝你"别把关系型范式直接搬过来"：范式化在一个没有廉价 JOIN 的系统里，等于把代价从写入期推到了每一次读取期。

2.4查询如何执行：多计划竞速、plan cache、SBE

第一次见到某查询形状，优化器并行试跑多个候选计划选最优，缓存它供后续复用。

底层机制（比文档深一层）：对一个新的查询形状（query shape，filter 结构相同、具体值不同算同一形状），multi-planner 会为每个候选索引各建一个计划，把它们并行试跑一小段 trial period，按"产出最多结果、做最少工作"的标准评出胜者，存入 plan cache。之后相同形状的查询直接复用缓存里的胜出计划，跳过竞速。当集合统计变化、或缓存计划的实际表现退化到阈值之下，会触发 replan，重新竞速。这和关系型的 plan cache / prepared statement plan 扮演同一个角色——把"选计划"的成本摊销到多次执行上。

计划选定后由执行引擎跑。SBE（slot-based execution engine，5.1 引入）把执行计划编译成基于 slot 的算子树，stage 之间通过 slot 传值，避免每个 stage 都物化一份中间 BSON 文档，从而降低 CPU 与内存开销；经典的 classic engine 则在 stage 之间反复物化文档。8.0 还加了 Express 快路径，专门加速最简单的单集合点查（按 _id 或单字段等值），绕过完整的计划流程。对照关系型，这一层等价于把 prepared statement 编译成更紧凑的执行代码。