应将引用改回内嵌，当被关联子文档体积小、读远多于写、且更新不频繁时——这能避免$lookup带来的非线性性能下降、高docsExamined及分片瓶颈。
$lookup频繁使用，通常不是性能问题的起点，而是数据模型已偏离访问模式的信号——该调整了。
频繁 $lookup 暴露的是读写分离设计与实际查询需求的错配
当业务中大量出现 $lookup（尤其是多级嵌套、多次 $lookup 或在高并发聚合管道中反复调用），说明你正在用“关系型思维”硬套文档模型：把本该一起读的数据拆到了多个集合，又靠运行时关联强行拼回来。
常见错误现象包括：
- 聚合管道执行时间随数据量增长非线性上升（比如从 100ms 跳到 2s+）
-
explain("executionStats")显示totalDocsExamined远高于nReturned，尤其在from集合上 - 分片集群中
$lookup目标集合（from）无法分片，导致所有关联请求都打到单个分片
这不是驱动或配置的问题，是模型层的设计债。MongoDB 不限制你写多少 $lookup，但它不优化它——$lookup 是 left outer join，无索引下推，无谓中间结果膨胀，且不能跨分片。
什么时候该把引用改回内嵌？关键看这三点
别一上来就重构，先确认是否真适合内嵌。以下任一条件成立，就值得把 group_ids 改成 groups 数组字段：
- 被关联的子文档（如
Groups）体积小（ - 每次查询都必须同时返回主文档 + 所有关联子文档（比如“查联系人详情页”必带分组名和营销状态）
- 写入场景中，主文档和子文档几乎总是原子更新（比如修改联系人所属分组的同时，也更新分组统计数）
注意：内嵌不是“把所有字段塞进去”，而是只存高频读、低频写、体积可控的必要字段。例如只嵌 { group_id: 1, name: "Friends", status: "active" }，而非整个 Groups 文档全量。
$lookup 无法规避时，至少得守住这三条底线
如果确实必须保留引用（比如分组有百万成员、名称每天改十次、还要支持按分组实时统计），那就接受 $lookup，但必须控制代价：
- 确保
localField和foreignField都建了独立索引（group_ids在Contacts上，group_id在Groups上） - 避免在
$lookup后再做$unwind+$match等导致数据放大的操作；优先在pipeline参数里加过滤（如{ pipeline: [{ $match: { status: "active" } }] }） -
from集合绝不能是分片集合——这是硬限制，不是建议；若Groups数据量大，宁可把它设为未分片的副本集，也不要强行分片后用于$lookup
最容易被忽略的点：内嵌 vs 引用不是静态选择，而是随生命周期演进的
很多团队卡在“一开始选错了”。其实 MongoDB 的灵活模式允许你渐进式迁移：先用引用支撑快速上线，等观察到某类 $lookup 占比超 70%、P95 延迟 > 800ms、且子集合更新率 groups_embedded_at: ISODate(...)）便于灰度验证。别等“完美时机”，数据访问模式不会自己收敛。
