MongoDB Atlas文档模型设计不当无法靠后期分片弥补，扩展性问题根源在建模阶段：嵌套适用于读多写少、数据稳定且体积小的场景（如用户地址），引用适用于频繁更新、数据量大或需独立生命周期管理的场景（如订单与商品），$lookup在分片集群中带来显著网络开销。
MongoDB Atlas 里文档模型设计不当，不是后期加个分片就能解决的——扩展性问题几乎全在建模阶段埋下。
嵌套文档 vs 引用文档：什么时候该用 $lookup？
嵌套（embedding）适合读多写少、关联数据稳定且体积小的场景；引用（referencing）更适合频繁更新、数据量大或跨集合需独立生命周期管理的情况。
- 用户地址信息：用嵌套，因为读取用户时总要一起展示，且修改频率低 —— 避免每次查用户都触发
$lookup - 订单与商品：用引用，商品库存、价格常变，嵌套会导致大量重复数据和更新不一致风险
-
$lookup在 Atlas 上有明确性能代价：聚合管道中每调一次，就多一次跨分片/跨节点网络往返，尤其在分片集群里容易成为瓶颈
分片键选错，再好的模型也扛不住流量
分片键决定数据怎么切、查询怎么路由。选错后无法更改，只能重建集群。
- 避免用高基数但低查询覆盖率的字段，比如
user_id虽然唯一，但如果大部分查询按created_at范围扫描，就会产生“热点分片” - 优先选复合分片键，例如
{tenant_id: 1, created_at: -1}：既支持租户隔离，又让时间范围查询能落在少数分片上 - 在 Atlas 控制台启用
shard key enforcement后，插入不符合分片键规则的文档会直接报错：Document failed validation
数组字段膨胀是静默杀手
数组无限追加（如日志、评论、标签）会让文档持续变大，最终触发 16MB 文档大小上限，且影响写入性能和内存占用。
- 超过 100 条记录的数组，建议拆成独立集合，用
post_id建索引，而非塞进主文档 - 如果必须保留数组，用 TTL 索引自动清理旧项：
db.logs.createIndex({ "timestamp": 1 }, { expireAfterSeconds: 2592000 }) - 注意
$push+$each+$slice组合虽能限长，但每次写都是全量重写数组，对大文档压力明显
Atlas 特有的建模陷阱：全局集群 vs 区域集群
你设计的模型可能在单区域跑得飞快，但在跨区域部署的 Atlas 全球集群里，延迟和一致性策略会彻底改变行为边界。
- 使用
readConcern: "majority"时，跨区域写入确认慢，若模型依赖强一致性读（比如秒杀库存），可能卡住 - 地理分片（
zone sharding）要求分片键包含地理位置字段，否则数据不会按区域分布 —— 单靠应用层路由没用 - 开启
atlasGlobalCluster后，_id默认仍是 ObjectId，但跨区域复制延迟可能导致短时间内出现“逻辑重复”（非真正重复，而是未同步前的幻读）
最常被跳过的一步：在 Atlas 的 Query Profiler 里跑真实业务查询，看 nReturned 和 executionTimeMillisEstimate 是否随数据量线性增长——模型是否可扩展，不在设计图里，在慢查询日志里。
