文档数据库模型因其灵活的数据结构在NoSQL领域广受欢迎，尤其嵌套文档设计能直观映射复杂业务关系。这种模型在查询与索引上面临诸多挑战，可能影响性能与扩展性。本文将从实际应用场景出发，分析嵌套文档的核心局限性，帮助开发者权衡设计选择。
**嵌套层级过深问题**
当文档嵌套层级超过3层时，查询性能显著下降。例如MongoDB对嵌套字段的索引仅支持有限深度，跨层级查询需全文档扫描。更新深层字段可能触发整个文档重写，导致写入放大问题。
**多条件组合查询低效**
嵌套文档的复合查询依赖多字段索引，但索引组合爆炸会占用大量内存。若查询条件涉及多个嵌套数组（如"orders.items.price>100"），数据库可能退化为全表扫描，即便单字段已建索引。
**索引维护成本高昂**
嵌套数组的索引会为每个数组元素创建独立索引条目。当数组频繁增删时（如评论系统），索引分裂与合并操作将拖累写入吞吐量。实测显示，包含10万条数组的文档更新延迟可达单字段的50倍。
**跨文档事务支持薄弱**
尽管部分数据库支持多文档事务，但嵌套文档的原子性通常仅限于单文档。若业务逻辑需跨文档一致性（如库存扣减与订单创建），只能通过应用层补偿机制实现，增加复杂度。
**结论**
嵌套文档适合读多写少、结构稳定的场景，但需规避深度嵌套与高频更新。实际设计中，可通过反规范化或混合关系模型平衡灵活性与性能。未来随着图数据库与NewSQL的演进，这一领域的解决方案将更趋多元化。