读多写少且查询路径固定时应放弃范式化，将低频更新、高频读取的字段（如profile、stats）嵌入主文档，预计算字段替代实时聚合，避免大文本和无界数组嵌入，强事务依赖字段须同文档存储。
读多写少且查询路径固定时，范式化会拖慢响应
当你的核心接口（比如用户个人主页、商品详情页）90%以上是读请求，且每次都要拼装用户+头像+关注数+最近3条动态+认证状态，而这些字段分散在 users、profiles、stats、auths 四个集合里，就必须放弃范式化。MongoDB 没有服务端 JOIN，应用层做 4 次查询 + 合并，网络延迟和序列化开销会直接让首屏 TTFB 翻倍。
实操建议：
- 把
profile和stats嵌入users文档——它们更新频率低（用户改头像/昵称不频繁），但读取极高频 - 用预计算字段替代实时聚合，比如
followers_count字段，而不是每次查follows集合再$count - 避免在嵌入结构中存大文本或二进制（如 base64 头像），改用 URL 引用，防止文档膨胀
数组持续增长超过 1000 条时，嵌入就变成定时炸弹
常见错误：把用户所有操作日志、全部订单历史、每条评论的点赞列表都塞进主文档的数组字段。一旦数组突破千条，文档体积快速逼近 16MB 上限，更新时容易触发文档迁移，CPU 和磁盘 I/O 会明显抖动，writeConcern 超时错误变多。
实操建议：
- 识别“增长无界”的数组：如
logs、order_history、likes—— 这些必须拆到独立集合 - 保留有限窗口的嵌入数据：比如只嵌入最近 5 条评论，其余用
comment_ids数组引用comments集合 - 对拆分后的集合建好复合索引，例如
{ userId: 1, createdAt: -1 }，确保分页查询不全表扫描
需要跨文档原子更新时，范式化反而破坏一致性
比如电商场景中，“扣减库存”和“生成订单”必须原子完成。如果把库存放在 products 集合、订单放在 orders 集合，即使开启 MongoDB 事务，跨集合事务性能差、超时风险高，且无法在分片集群中跨 shard 使用。
实操建议：
- 将强事务依赖的字段收拢到同一文档：把
stock字段嵌入products文档，用findAndModify或updateOne的upsert+ 条件更新实现原子扣减 - 接受最终一致性的地方才用引用：比如“用户积分变动”和“积分流水记录”，可以分开，靠消息队列补偿
- 注意
$inc操作只能用于数值字段，别试图对嵌入文档里的对象用它
查询条件涉及多个父级文档关联时，引用模型会让聚合管道失控
典型症状：写一个 $lookup 就不够，得套两层甚至三层 $lookup，再加 $unwind 和 $group，最后发现 pipeline 执行时间 >2s，explain() 显示大量内存溢出警告。
实操建议：
- 把高频联查路径反范式化：比如“查某城市所有带认证标签的餐厅及其平均评分”，就把
city、isVerified、avgRating直接冗余进restaurants文档 - 冗余字段加
@Indexed（Spring Data）或createIndex，避免全文档扫描 - 冗余字段更新走应用层双写 or Change Stream 监听，别依赖定时任务同步——延迟不可控
