问题现象
在 MongoDB 中，嵌套文档能减少关联查询，但嵌套过深会带来性能问题：
- 查询变慢，尤其是需要遍历深层数组或对象时。
- 文档体积膨胀，可能触及 16MB 文档上限。
- 更新深层字段时，整个文档可能被重写，影响写入性能。
- 索引难以有效覆盖嵌套字段，导致全文档扫描。
为什么嵌套会变慢
MongoDB 以文档为单位读写。当嵌套层级很深时：
- 查询需解析整个文档结构：即使只匹配内层字段，引擎也可能需要加载并检查整个文档。
- 数组嵌套导致索引效率下降：多级数组上的索引（如
a.b.c）可能无法高效过滤，尤其是数组内还有数组时。 - 文档大小影响内存与 IO：大文档占用更多内存，缓存命中率降低，磁盘 IO 增加。
- 更新代价高：修改内层字段可能导致文档移动或重写，影响并发写入。
什么时候该拆成引用式建模
考虑以下信号，若出现多个，建议拆分为引用式（类似关系型的外键）：
- 嵌套层级超过 3 层，且查询经常需要跨层过滤。
- 数组元素数量无上限，例如评论、日志、订单明细。
- 文档大小接近或超过 1MB（16MB 上限的 1/16 作为警戒线）。
- 更新频繁且集中在深层字段，导致写放大。
- 需要独立查询子文档，例如按评论时间、用户 ID 单独检索。
- 子文档被多个父文档共享，如地址、标签。
拆分的具体做法
以“订单-商品”为例，原嵌套模型：
{
_id: "order1",
items: [
{ productId: "p1", name: "A", price: 10 },
{ productId: "p2", name: "B", price: 20 }
]
}
拆分为引用式：
- 订单集合：只存
_id、userId、total等。 - 订单明细集合：每条记录含
orderId、productId、name、price。
查询时用 $lookup 聚合关联，或应用层二次查询。
关键步骤：
- 识别高频查询路径，确定哪些字段需要一起返回。
- 将无界数组或深层对象移到独立集合。
- 在子集合上为外键（如
orderId）建立索引。 - 若需原子性，使用多文档事务（MongoDB 4.0+ 支持副本集事务）。
- 评估读性能：
$lookup可能比嵌套慢，但可通过索引和限制返回字段优化。
权衡与替代方案
- 不要盲目拆分：如果子文档总是随父文档一起读取，且数量有限（如几十个），嵌套仍是最佳选择。
- 折中方案：使用“子集嵌套”——只嵌套常用字段，完整数据放引用集合。
- 预聚合：对统计类查询，可用物化视图或定期汇总。
- 索引优化：为嵌套字段创建索引时，注意多键索引的限制，避免在数组内数组上建索引。
总结
嵌套适合“一对一”或“少量一对多”且总是一起读取的场景。当嵌套导致查询慢、文档大、更新频繁时，拆成引用式建模能显著提升灵活性与性能。实际决策应基于查询模式、数据增长预期和一致性要求，必要时通过 explain() 分析执行计划来验证。