$lookup在分片集群中默认不推送到分片执行，导致全量数据拉取至mongos；MongoDB 4.4引入交换算子下推机制，但需满足右表未分片（或同shard key）、关联字段为_id或唯一索引、且无pipeline三个条件。

为什么 $lookup 在分片集群里特别慢？

因为默认情况下，$lookup 不会下推到各个分片执行，而是在 mongos 上把左表数据拉回来再做关联——相当于把所有分片的匹配文档全扫一遍传到 mongos，网络和内存压力都很大。MongoDB 4.4 引入了“交换算子下推”（exchange pushdown）机制，但仅对满足特定条件的 $lookup 和 $unwind 生效，并非自动开启。

关键前提有三个：右表必须是未分片集合（或与左表同 shard key），关联字段必须是右表的 _id 或唯一索引字段，且 $lookup 不能带 pipeline（即不能用 pipeline 字段）。一旦用了 pipeline，整个 stage 就退回到 mongos 执行。

• 错误写法：{ $lookup: { from: "orders", localField: "order_id", foreignField: "_id", as: "order", pipeline: [ { $match: { status: "paid" } } ] } } → 必然不走下推
• 正确写法（可下推）：{ $lookup: { from: "orders", localField: "order_id", foreignField: "_id", as: "order" } }，前提是 orders 是未分片集合，且 _id 有唯一索引
• 验证是否下推：开启 profiler（db.setProfilingLevel(2)），查 slowms 日志里是否有 "executionStages.stage": "LOOKUP_SHARDING"

$sort + $skip + $limit 组合为何在分片下容易 OOM？

mongos 默认把 $sort 下推到各分片，但每个分片只返回自己的 top-N 结果；如果 N 很大（比如 $limit: 1000），而分片数是 8，mongos 就要合并 8000 条记录再全局排序——中间结果可能远超内存上限。4.4 的交换算子优化允许把 $sort 后置的 $skip/$limit 下推成“局部裁剪”，但需满足：sort key 必须包含 shard key 前缀，且不能有 $group 或 $facet 等阻断下推的 stage。

• 有效下推示例：{ $sort: { "region": 1, "created_at": -1 } } + { $limit: 50 }，当 region 是 shard key 时，各分片可直接返回前 50 条，mongos 合并后取全局 top 50
• 无效场景：{ $sort: { "amount": -1 } } → 无法下推，所有分片必须返回全部数据供 mongos 排序
• 实操建议：用 explain("executionStats") 查看 shards.*.executionStages.stage 是否出现 "SORT_SHARDING"，而不是 "SORT"

如何强制触发交换算子下推？绕过自动判断失败的情况

MongoDB 4.4 不提供显式开关，但可通过重写查询结构“提示”优化器启用交换算子。最常用的是把原本在 mongos 层做的过滤，提前塞进 $lookup 的 let+pipeline 中——但这看似矛盾：前面说 pipeline 会禁用下推。其实有个例外：当 pipeline 内只含 $match 且 match 条件能被下推为索引扫描时，4.4 仍可能启用 exchange（需配合 hint 和合理索引）。

• 可行写法：{ $lookup: { from: "logs", let: { uid: "$user_id" }, pipeline: [ { $match: { $expr: { $eq: [ "$user_id", "$$uid" ] } } } ], as: "user_logs" } }，前提是 logs 集合在 user_id 上有索引，且 logs 是未分片集合
• 必须加 hint：db.orders.explain("executionStats").aggregate([...], { allowDiskUse: true, hint: { "user_id": 1 } })，否则优化器可能忽略索引路径
• 注意：这种写法在 5.0+ 被更稳定的 $lookup with collation 和分布式 join 支持替代，4.4 下属于“技巧性兜底”

最容易被忽略的性能断点：$unwind 后没跟 $match 过滤空数组

$unwind 在分片下默认不触发交换下推，除非后面紧跟一个能利用 shard key 的 $match。如果 $unwind 产生大量空文档（比如 as: "items" 但某些订单无 items），这些空文档仍会跨网络传输，白白消耗带宽和 CPU。4.4 的优化逻辑是：只有 $unwind + $match（且 match 涉及 items 字段）才能触发“空值裁剪下推”。

• 危险写法：{ $unwind: "$items" } → 所有分片把 null/missing 数组元素展开成空文档，全发给 mongos
• 安全写法：{ $unwind: "$items" } + { $match: { "items.sku": { $exists: true } } } → 各分片可在 unwind 后立刻丢弃空项，不传输
• 验证方式：对比 explain 中 shards.*.executionStages.nReturned，优化前可能是 10w，优化后应显著下降

交换算子下推不是银弹，它高度依赖查询结构、索引设计和分片键选择。哪怕只漏掉一个 $match 或建错一个索引，整个管道就退回低效模式——调优时得盯着每个 stage 的实际执行位置，而不是只看逻辑写法。