mongodb设计阶段应基于读写特征决定冗余字段：高频读、低频改、小体积、语义稳的字段（如user.name、category.name）适合冗余，且必须配套创建覆盖查询的复合索引并设置合理writeconcern保障一致性。
MongoDB 设计阶段就该决定冗余字段的取舍，而不是等上线后靠加索引硬扛慢查询。读多写少场景下，适度冗余能直接把 nReturned 和 totalDocsExamined 拉到 1:1，否则单次订单详情查询可能触发三次网络往返+全表扫描。
哪些字段适合冗余？看四个硬指标
冗余不是拍脑袋决定的，得同时满足：
• 高频读：比如 user.name 在订单列表页每行都展示
• 低频改：用户改名平均一年不到一次，而订单每秒新增几十条
• 小体积：product.sku 通常不超过 32 字符，但 user.avatar_url 可能带签名参数且长度飘忽
• 语义稳：category.name 很少重命名，而 order.items 是动态数组，嵌套再冗余等于制造同步地狱
冗余字段不建索引=白干
很多人加了 user_name 字段却忘了建索引，结果 explain("executionStats") 显示 totalDocsExamined 是 nReturned 的 10 倍——说明 MongoDB 还是在扫文档，只是把字段从 JOIN 搬到了文档里。
必须做两件事：
• 所有投影字段（{user_name:1, product_title:1}）要进同一个复合索引，例如：db.orders.createIndex({status:1, user_name:1, product_title:1})
• 检查 executionStats.totalKeysExamined 是否 ≈ nReturned；如果不是，说明索引没覆盖全，或者查询条件用了未索引字段
写操作一致性必须跟冗余程度对齐
一个用户信息冗余在 5000 个订单里，用 w:1 写入改名操作，极可能部分成功、部分失败，最终页面上同一用户显示两个名字。
此时必须提升写关注：
• 更新冗余字段时显式指定：writeConcern: {w: "majority", j: true}
• 避免全局设成 w:"majority"，否则所有写操作都变慢；只对 updateMany 类批量更新加严
• 如果业务能容忍短暂不一致（比如昵称延迟 2 秒刷新），可用 readConcern: "available" 从主节点快速读，不等复制完成
冗余和索引是绑定动作，漏掉任意一环都会让存储空间涨了、读却没快——而且问题往往在线上流量高峰才暴露，因为低负载时缓存掩盖了扫描代价。
