MongoDB中数据冗余是权衡策略，需在读多写少、查询路径固定时用空间换时间；应冗余低变更、非核心字段，避免强一致性或高频更新字段，并警惕更新维护与分片约束。
数据冗余在MongoDB中不是“要不要做”的问题，而是“在哪做、做多少、为什么这么做”的权衡。它本质是用空间换时间、用一致性成本换查询效率的策略，不能凭直觉加，也不能一概禁止。
读多写少且查询路径固定时，冗余能显著降低查询复杂度
当某个字段（比如用户昵称、课程标题）被高频读取，但极少修改，且总是和主文档一起返回（例如 find({ _id: "xxx" }) 后必须带出该字段），直接冗余比每次 $lookup 更快、更稳定。
- 典型场景：订单文档中嵌入
user_name和product_name，而不是只存user_id和product_id - 注意点：如果昵称变更频繁（如社交平台允许实时改名），冗余字段就得同步更新多个订单文档——这时就要评估更新成本是否可接受
- 不适用场景：用户头像URL这类可能频繁轮换的字段，冗余反而增加维护负担
避免跨集合聚合或多次往返时，冗余是实际可行的简化手段
当业务逻辑要求“一次请求返回课程+讲师+所有课时标题+每个课时的完成状态”，而这些数据天然分散在 courses、instructors、lessons、user_progress 四个集合时，$lookup 链式调用不仅慢，还容易触发内存限制（Exceeded memory limit for $lookup）。
- 可行做法：在课程文档中冗余存储讲师基础信息（
instructor.name,instructor.avatar），并在每个lessons子文档里直接记下完成状态（{ title: "...", completed: true }） - 关键约束：冗余字段必须是“低基数、低变更频率、非核心业务状态”。比如完成状态可以冗余，但支付流水号绝不能冗余到订单文档外
- 陷阱：别把冗余当成偷懒借口——如果某字段需要强一致性校验（如库存数量），宁可加事务或用引用，也不冗余
分片环境下，冗余能绕过跨分片 $lookup 的性能黑洞
MongoDB分片集群中，$lookup 无法跨分片高效执行（除非目标集合也按相同键分片且启用 allowDiskUse）。此时，把被关联方的少量关键字段冗余进主文档，是最直接的规避方式。
- 示例：订单集合按
user_id分片，用户信息存在另一按_id分片的集合——这种分片键不一致导致$lookup变成广播查询，延迟飙升 - 解决：在订单文档中冗余
user.region、user.tier等用于筛选/分组的字段，避免运行时关联 - 代价：分片键设计一旦固化，后续想把冗余字段改成引用会非常困难；所以冗余前得确认这些字段未来不会成为高并发更新热点
change stream 或没写好批量更新脚本的冗余字段，比没有冗余更危险。 
