$lookup在分片集群中默认不支持跨分片Join，会触发广播式聚合，导致性能骤降；应改用字段冗余、同键分片或应用层双查替代。
$lookup在分片集群中默认不支持跨分片Join
它不是“不能用”，而是用了就大概率触发广播式聚合——mongos把整个 $lookup 请求发给所有分片，每个分片都查一遍 from 集合，再把结果全拉回 mongos 合并。语法合法、返回正常，但耗时可能从 20ms 跳到 8s，尤其在数据量大或 pipeline 后接 $sort 时更明显。
根本原因在于：MongoDB 无法根据 localField/foreignField 的值，把关联查询路由到目标分片。只要 from 集合是分片的，且关联字段 ≠ 其分片键（或前缀），就必然广播。
- 错误示例：
{from: "users", localField: "userId", foreignField: "_id", as: "user_info"}—— 若users按{tenantId: 1}分片，userId不在其分片键中，必跨片 -
allowDiskUse: true对此无效：它只缓解单分片内存溢出，不减少网络传输和广播开销 - 检查方式：运行
explain("executionStats")，看executionStages.shards是否列出全部分片；再搜 mongos 日志里的scatterGather
唯一可控的跨分片关联写法：let + pipeline + 分片键对齐
基础 $lookup 的 localField/foreignField 模式在分片下基本失效，必须改用 let + pipeline 形式，并确保两个集合的关联字段都是各自分片键的前缀。
- 安全前提：主集合分片键为
{tenantId: 1, orderId: 1}，被关联集合orders分片键也为{tenantId: 1} - 正确写法：
{from: "orders", let: {tid: "$tenantId"}, pipeline: [{$match: {$expr: {$eq: ["$tenantId", "$$tid"]}}}], as: "order_list"} - 关键点：
$$tid来自主集合分片键字段，$match中的$tenantId是orders集合的分片键字段，MongoDB 才能将该 pipeline 下推到对应分片执行 - 若 pipeline 中用了未索引字段（如
$status）做匹配，仍会全表扫描 + 跨片拉取
比优化 $lookup 更有效的三个实操替代方案
试图靠加索引、调参数或换写法让跨分片 $lookup 变快，本质是走错方向。真正落地的解法只有三个，且都绕开了分布式 join：
- 字段冗余：把高频关联字段（如用户昵称、商品名称）直接存进主文档。用应用层保证一致性（比如更新用户昵称时，同步批量更新订单中的
userName字段） - 同键分片：强制
orders和users都按{tenantId: 1}分片，并在所有$lookup中只使用tenantId或其前缀做关联变量 - 应用层双查：先查主集合拿到 ID 列表（如
db.orders.find({tenantId: "t1"}, {_id: 1})），再用find({_id: {$in: [...]}})查副集合 —— 这样$in查询可被路由到具体分片，避免广播
为什么 explain 里看到 shards 数量多 ≠ 一定有问题？
容易被忽略的一点：explain 输出中 shards 字段列出多个分片，不代表当前查询一定跨片。如果 from 集合是 unsharded（即副本集），即使主集合分片了，$lookup 也会被下发到所有分片去查同一份副本集数据 —— 此时是“伪跨片”，实际没广播，性能影响小。
真问题的标志是：totalDocsExamined 在各分片上远高于该分片实际文档数，或 executionStages 中出现大量 COLLSCAN 且 stage 名为 SHARDING_FILTER，说明 mongos 正在过滤跨片拉回来的冗余数据。
