内嵌文档能绕过事务开销并提升性能，因其支持单文档原子操作、减少跨文档查询与分布式事务复杂性，但需规避文档超限、高频单独访问及频繁独立更新等风险。
内嵌文档能绕过事务开销，因为单文档操作天然原子
MongoDB 对单个文档的写入是原子的，这个特性直接来自 WiredTiger 存储引擎的文档级锁和 MVCC 实现。只要把相关数据塞进同一个文档里，比如把订单详情、收货地址、支付状态全放在 order 文档中，更新整个订单就只需一次 updateOne，不用开启事务、不用协调多个文档、也不会触发 WriteConflict 错误。
反观多文档事务，哪怕只改两个文档，也要走快照隔离 + oplog 广播 + 多数派确认（副本集）或两阶段提交（分片集群），链路长、延迟高、失败率上升。生产环境里一个 session.startTransaction() 调用背后，实际在消耗 CPU、网络和锁资源。
内嵌减少跨文档查询，避免 N+1 和聚合性能陷阱
电商场景中，查一个订单要同时拿到商品列表、优惠券、物流轨迹——如果这些都拆成独立集合，每次查询就得发多次请求，或者硬上 $lookup。而 $lookup 在分片集群里无法下推到分片节点执行，所有数据得拉到 mongos 再做关联，内存和网络压力陡增。
内嵌后，一次 find({ _id: ObjectId("...") }) 就返回全部所需字段，连索引都可以建在内嵌路径上，比如 { "items.sku": 1 }，查询效率直线上升。
- 数组字段如
items要控制增长：超过几百条就该考虑拆出去，否则文档可能超 16MB 限制 - 高频单独访问的子对象（如用户评论）不适合内嵌，否则每次查用户基本信息都得加载全部评论
- 内嵌字段若经常被单独更新（如只改物流状态），WiredTiger 仍能只写脏页，不影响整体性能
事务在分片集群里代价翻倍，内嵌能强制数据局部性
跨分片事务必须走两阶段提交（2PC），协调器要跟每个涉及的分片反复握手，准备、预提交、最终确认，任何一个分片响应慢或失败，整个事务就卡住或回滚。更麻烦的是，MongoDB 不保证事务内所有文档自动落在同一分片上——除非你用共享的分片键把它们“绑”在一起。
而内嵌天然把强关联数据打包在一个文档里，只要分片键设计合理（比如用 userId 分片，把该用户的全部订单内嵌进一个大文档），就能确保所有读写都在单一分片完成，彻底避开分布式事务的复杂性和延迟。
注意：shard key 一旦设定就不能改，所以建模阶段就要想清楚哪些字段最常用来路由请求。
内嵌不是万能的，但错误地用事务会掩盖模型缺陷
很多团队一遇到“需要同时更新订单和库存”，第一反应是加事务，却没问：为什么库存不能直接记在订单文档里？或者为什么不能用原子操作 findAndModify 去扣减库存字段？真正难处理的其实是跨业务实体的强一致性，比如“支付成功 + 发货通知 + 积分到账”，这种本就不该靠数据库事务兜底，而该用消息队列 + 补偿逻辑。
事务容易让人忽略数据访问模式本身是否合理。一个总在事务里被频繁读写的文档，大概率说明它本该是主实体；而总被拆出来、又总要和别的文档一起查的，大概率该合并。模型没理清就上事务，只会把问题从应用层转移到数据库层，还更难排查。
