嵌入式订单数组适合用户平均订单数少于100条、订单极少单独更新、查询总是获取用户及全部订单的场景；此时MongoDB单次读取即可返回完整数据，简单高效，但受限于16MB文档大小且写放大严重。
嵌入式订单数组适合什么场景
当用户平均订单数少于 100 条、且订单几乎不单独更新（比如很少修改某笔订单状态）、查询总是「查用户+全部订单」时，直接把订单数组嵌入 users 文档最省事。MongoDB 一次读取就能拿到完整数据，不用多次网络往返。
- 示例结构：
{ _id: ..., name: "张三", orders: [ { orderId: "1", product: "手机", status: "paid" }, ... ] } - 优点：简单、快、代码少；
orders字段天然支持索引（如orders.orderId） - 坑点：单文档不能超过 16MB；如果某用户有几千笔订单，文档会撑爆；更新单个订单需重写整个
users文档，写放大严重
引用式设计何时必须用
当订单需要独立增删改查、或单用户订单量不可控（比如电商平台老用户可能有上万单）、或订单要被多个集合关联（如关联物流、支付记录）时，必须拆成 users 和 orders 两个集合，用 userId 字段引用。
- 典型操作：
db.orders.find({ userId: "123" })查所有订单；db.orders.updateOne({ orderId: "1" }, { $set: { status: "shipped" } })独立更新 - 关键点：在
orders.userId上建索引，否则关联查询极慢；别漏掉orders.orderId唯一索引 - 坑点：应用层要自己做两次查询（先查用户，再查订单），或用聚合管道
$lookup—— 但$lookup在大数据量下性能不如分步查，且无法利用orders集合的复合索引优化排序
聚合管道 $lookup 不是万能胶
$lookup 看起来能“模拟 JOIN”，但实际受限明显：它只支持左连接、不支持子查询、内存限制严格（默认 100MB），且结果无法用下游集合的索引加速。
- 适用情形：临时性报表、后台管理页一次性拉取少量用户+订单；字段不多、总数据量
- 危险信号：聚合返回
Exceeded memory limit for $lookup错误；$lookup后跟$sort却没在orders上建对应索引，导致全表扫描 - 替代思路：优先考虑应用层两次查询 + 缓存；或预计算视图（
create view），但注意视图是只读且不存数据的
混合模型容易被低估的维护成本
有人想“折中”：用户文档里存最近 10 条订单（嵌入），历史订单放 orders 集合（引用）。这看似兼顾读写，实则让业务逻辑变复杂——每次新增订单都要判断是否该归档、查订单要合并两路数据、分页逻辑断裂、事务难保证原子性。
- 除非有明确压测数据证明嵌入部分命中率 > 95% 且延迟敏感，否则别轻易引入混合
- 真正需要动态伸缩的场景（如订单量随时间指数增长），应从一开始就选纯引用模型，用分片键（如
userId）分散压力 - 最容易被忽略的点：迁移成本。上线后想从嵌入改成引用，要写迁移脚本、停写窗口、校验一致性——远比一开始选对模型麻烦得多
