MongoDB一对多关系应据读写模式选择：嵌入式适用于子数据量小、读多写少、总一起访问的场景，如用户地址；引用式适用于子数据量大、需独立生命周期或高频单独查询的场景，如订单。
MongoDB 一对多关系没有“标准答案”，只有“更适合当前读写模式”的选择。嵌套文档（Embedded）和 Manual Reference 是两种最常用、也最容易误用的建模方式——选错会导致查询变慢、更新出错、甚至文档超限崩溃。
什么时候该用 embedded 数组？
嵌套适用于「子数据量小、读多写少、且几乎总是一起访问」的场景。比如用户收货地址、文章标签、设备配置项。
- 单文档大小不能超过
16MB，所以addresses数组里别塞几百条历史地址 - 更新某一条嵌入地址时，要用
$set精准定位：例如db.users.updateOne({ _id: "u1" }, { $set: { "addresses.1.city": "Shanghai" } })，而不是整个数组重写 - 无法单独对嵌入数组做索引排序（如“查所有状态为 pending 的订单”），除非用
arrayFilters配合$elemMatch，但语法绕、性能弱 - 如果子文档需要被其他集合引用（比如订单要关联支付记录），嵌入会让跨文档事务或原子更新变得不可行
什么时候必须用 Manual Reference？
当子数据具备独立生命周期、数量不可控、或需高频单独查询时，Manual Reference 是唯一合理选择。典型如用户订单、日志事件、评论列表。
- 引用字段名建议统一用
user_id而不是owner或parent，避免语义模糊 - 务必在引用字段上建索引：
db.orders.createIndex({ user_id: 1 })，否则find({ user_id: "u1" })会全表扫描 - 应用层需主动处理 N+1 查询问题：一次查用户，再查其所有订单，不能依赖 MongoDB 自动拼接
- 不要把引用 ID 存成字符串（如
"507f1f77bcf86cd799439011"），而要用原生ObjectId类型，否则索引无效、比较失败
db.collection.findOne() 返回后，怎么安全取关联数据？
这不是 MongoDB 自动做的事，得靠你控制查询节奏。常见错误是先查父文档，再循环每个子 ID 单独发请求——这会放大延迟、压垮连接池。
- 推荐批量查：拿到用户 ID 列表后，用
db.orders.find({ user_id: { $in: [ObjectId("..."), ObjectId("...")] } }) - 如果只查“最近 5 条订单”，别在父文档里存个
last_5_order_ids数组来作弊——这违背单一数据源原则，容易不同步 - 聚合管道里可以用
$lookup做左连接，但注意它不走索引，大数据量下比应用层两查还慢；仅适合低频、离线分析类场景
最容易被忽略的一点：嵌入和引用不是静态设计，而是随业务演进的。今天用户平均只有 3 个地址，嵌入很稳；三年后变成平均 87 个，就得拆。别指望一劳永逸，定期看 db.collection.stats().avgObjSize 和慢查询日志，才是真实建模的起点。
