嵌入式文档适合一次性读取完整业务实体且子数据变动不频繁的场景，如商品详情页展示name、price、specifications和reviews等全部字段，一次find()即可获取，无需$lookup或多次查询。
嵌入式文档适合哪些查询场景
当应用需要一次性读取完整业务实体，且子数据变动不频繁时，embed 是最直接的选择。比如商品详情页要展示 name、price、specifications 和 reviews，全部内嵌在一个文档里，一次 find() 就能拿到全部字段，不用 $lookup 或多次查询。
但要注意边界：如果 reviews 每天新增上百条，或单个文档逼近 16MB 上限，就容易触发写放大和内存压力。MongoDB 的文档更新是全量替换（除非用 $set 等原子操作），嵌套数组过长会导致 WiredTiger 页面分裂加剧。
- 适用条件：子文档数量稳定（如
specifications通常固定在 5–10 个字段）、读多写少、查询总是“一起出现” - 风险点：
reviews类数组持续增长；多个业务线反复追加不同结构的嵌套字段，最终导致文档结构失控 - 验证方式：用
db.collection.stats()查看avgObjSize和maxSize，若长期 > 8MB 就该警觉
什么时候必须用引用式设计（ObjectId + $lookup）
当子集合存在高基数、异构结构或写入时间错峰时，硬塞进主文档只会让问题更难收敛。典型例子是课程平台里的 lessons：每节课可能含视频、测验、PDF、外部链接，格式差异大，且编辑频率远高于课程基本信息。
这时拆成独立集合，用 course_id: ObjectId("...") 关联，好处是：单节课可独立增删改查；不同课时复用同一套索引策略；避免某门爆款课把整个课程文档撑爆。
- 必须拆分的信号：
db.courses.findOne().lessons.length > 50；同一字段在不同文档中类型不一致（比如有的lesson.type === "video"，有的却是"quiz"）；后台任务需单独扫描所有课时做统计 - 代价明确：每次查课程+课时得走
$lookup，性能比嵌入慢 2–5 倍（取决于网络延迟和内存命中率）；事务需跨集合，4.0+ 才支持多文档事务 - 折中方案：对高频访问的前 3 节课时仍嵌入，其余用引用——但会增加应用层逻辑复杂度
shard key 选错会导致什么实际后果
分片不是加机器就能扩容，shard key 一旦选定，几乎无法在线修改。选错的后果很具体：集群负载严重倾斜、某些分片磁盘提前告急、mongos 路由失效后查不到数据。
比如用 user_id 当分片键，但业务发现 80% 的请求都集中在最近注册的 1000 个用户身上（比如网红账号带货），那这些用户的数据全落在同一个分片上，其他分片空转——这叫“热分片”，比单机还难扛。
- 安全选择：优先选高基数、低热点、查询中高频出现的字段，例如订单系统的
order_id（UUID 或时间戳混合）比status更合适 - 绝对避开：
created_at单独作分片键（导致所有新数据写入同一分片）；boolean字段（只有 true/false，最多两个 chunk） - 验证手段：部署后跑
sh.status()，观察各分片的chunks数量是否均衡；用db.collection.getShardDistribution()查数据分布
副本集节点数为什么不能是 2
三节点不是为了“多一个备份”，而是满足“多数派（majority）”选举底线。MongoDB 副本集要求至少 ceil(n/2) + 1 个节点存活才能选出主节点。两节点时，只要挂一个，剩下那个无法达到多数（2/2=1，但需要 ≥2），整个集群只能读、不能写。
真实运维中，网络分区比硬件宕机更常见。比如机房 A 的两个节点之间网络抖动，它们互相认为对方失联，就会陷入“双主”风险或双双降为从节点——而三节点下，哪怕一个节点网络异常，另外两个仍能通信并维持多数派。
- 隐藏坑：
arbiter节点虽不存数据，但参与投票，可用来凑奇数（如 2 数据节点 + 1 arbiter），但 arbiter 不能替代数据节点的灾备能力 - 四节点反而更危险：挂两个就剩一半，刚好卡在多数派边缘（4/2=2，需要 ≥3），不如三节点容错清晰
- 关键检查：
rs.status().members.map(m => m.stateStr)应始终看到一个PRIMARY和至少两个SECONDARY，否则选举机制已在报警
