真正能减少冗余、支持独立生命周期管理的是规范化的Manual Reference模式，但必须配合索引、类型、批量查询三要素；否则性能更差。
嵌入式建模在一对多场景下容易导致数据冗余和更新扩散，真正能减少冗余、支持独立生命周期管理的，是规范化的 Manual Reference 模式——但必须配合索引、类型、批量查询三要素，否则性能反而更差。
为什么 user_id 字段不加索引会让查询变全表扫描
MongoDB 不像关系型数据库那样自动为外键建索引。当你用 db.orders.find({ user_id: "u1" }) 查询时，若未显式创建索引，MongoDB 会遍历整个 orders 集合。
- ObjectId 类型的引用字段必须用原生
ObjectId存储，不能存字符串形式的 ID；否则db.orders.createIndex({ user_id: 1 })创建的索引无效，查询仍走全表 - 复合查询如
find({ user_id: ..., status: "pending" })，建议建复合索引：db.orders.createIndex({ user_id: 1, status: 1 }) - 索引需在写入数据前建立；已有大量无索引数据后再建，会阻塞写入且耗时长
避免 N+1 查询：别在循环里调 findOne()
常见错误是先查用户，再对每个用户的订单 ID 单独发一次 db.orders.findOne({ _id: ... }) ——这会产生连接数爆炸、延迟叠加、超时风险。
- 正确做法是批量提取 ID 后一次查：
db.orders.find({ _id: { $in: [ObjectId("..."), ObjectId("...")] } }) - 如果只取“最近 5 条”，不要在用户文档里维护
last_5_order_ids数组，那会引入双写一致性问题 - 聚合管道中用
$lookup看似方便，但它不走索引，大数据量下比应用层两查还慢，仅适合后台导出或低频分析
什么时候该把引用从数组移到单独集合
当父文档里开始出现 books: [ObjectId(...), ObjectId(...), ...] 这类长数组，且元素数量持续增长、单文档逼近 16MB 上限时，说明引用模式已退化为“伪嵌入”。
- 数组长度超过 100 条后，
$push/$pull更新性能明显下降，尤其是带upsert: true的场景 - 若子文档需要被多个父文档引用（比如一个订单关联多个优惠券），就必须拆到独立集合，否则无法建唯一约束或反向索引
- 引用字段名统一用
user_id、product_id等语义明确的命名，避免owner、ref这类模糊字段，后期加聚合或迁移时容易歧义
最容易被忽略的是：引用不是一劳永逸的设计。当某个用户突然产生 1000+ 订单，或者地址变更频率从每月 1 次变成每天 5 次，原来的嵌入模型就得切到引用——模型得跟着读写压力走，而不是定死在初版 schema 里。
