$lookup跨分片变慢是因为触发广播式聚合：mongos需向所有分片发送查询，合并结果时产生大量网络往返、序列化开销和内存缓冲延迟；分片键不匹配或关联字段未索引时，无法路由至单一分片，导致全分片扫描。
为什么 lookup 跨分片会变慢？
MongoDB 的 lookup 在分片集群中一旦涉及非本地分片的集合，就会触发“广播式聚合”：mongos 必须把查询发给所有分片，等每个分片返回中间结果后，在 mongos 层做合并。这不是简单的 join，而是分布式归并，网络往返 + 结果集序列化/反序列化 + 内存缓冲都会拖慢速度。
- 分片键不匹配时，
$lookup的 from 集合若没按关联字段分片，就无法路由到单一分片 - 即使 from 集合有分片键，但 pipeline 中用了未索引字段做匹配，仍可能全表扫描 + 跨片拉取
-
allowDiskUse: true不能缓解跨片瓶颈，它只解决单分片内存溢出问题
$lookup 跨分片却没报错，但响应超时
这是最典型的“静默性能退化”：语法合法、执行成功，但耗时从几十毫秒跳到几秒甚至分钟。尤其在聚合 pipeline 后续还有 $match、$sort 时，延迟会被放大。
- 检查执行计划：
explain("executionStats")中看shards数量和各分片的nReturned是否远大于预期 - 关注
totalDocsExamined和totalKeysExamined：如果远高于目标文档数，说明发生了低效扫描 - mongos 日志里搜
scatterGather或remote execution，能确认是否真跨片了
用 let + $expr 做关联时，分片键必须对齐
$lookup 的 localField/foreignField 模式在分片下基本不可靠；改用 let + $expr 是唯一可控方式，但前提是两个集合的关联字段都是各自分片键的前缀。
- 如果主集合分片键是
{tenantId: 1, orderId: 1}，那let: {tid: "$tenantId"}是安全的 - 但若试图用
"$status"（非分片键字段）去关联另一集合，哪怕该集合也按tenantId分片，MongoDB 仍无法路由，只能广播 - 示例中常见错误写法：
{from: "orders", let: {uid: "$userId"}, pipeline: [{$match: {$expr: {$eq: ["$userId", "$$uid"]}}}]}—— 若orders按tenantId分片，userId不是其分片键，这就必然跨片
真正规避跨片 lookup 的三个实操动作
不是加索引或调优就能解决，得从数据模型和查询路径上动手：
- 把高频关联的字段冗余进主集合，用应用层保证一致性，换掉
$lookup（比如把用户昵称存进订单文档） - 将两个集合按同一分片键（如
tenantId）分片，并确保所有$lookup的let变量都来自该键或其前缀 - 实在要跨集合查，改用应用层双查：先查主集合拿到关键 ID 列表，再用
find({_id: {$in: [...]}})查副集合 —— 这样至少能利用分片路由，避免广播
跨分片 lookup 的坑不在语法，而在你根本看不出它正把整个集群当单机用。只要 pipeline 里出现 $expr 关联、且关联字段没对齐分片键，就默认已掉进这个坑。
