一对多场景应采用引用式建模：将“多”侧数据拆入独立集合，用 objectid 类型的 user_id 字段关联并建立复合索引，配合游标分页与批量查询，避免嵌入导致的 16mb 上限、io 剧增及索引失效问题。
一对极多场景该用引用而非嵌入
当“多”侧数据量达到几千甚至上万条（比如用户有数万条评论、设备产生海量传感器读数），嵌入式建模会直接撞上 16MB 文档上限，且每次更新都要重写整个大文档，IO 和锁开销剧增。此时必须切到引用式建模：把“多”侧拆成独立集合，用 user_id 或 device_id 字段指向主文档。
常见错误是仍试图在用户文档里维护一个 comment_ids 数组——这个数组本身就会膨胀、难以原子更新，且无法支持按时间/状态等条件高效筛选子集。真正可扩展的结构是：
- users 集合只存用户基本信息
- comments 集合每条记录含
user_id（必须是 ObjectId 类型）、content、created_at等字段 - 不存反向数组，也不用
$push维护 ID 列表
user_id 字段必须加索引，且类型要对
没索引的 user_id 查询等于全表扫描，哪怕只有 10 万条评论，响应也可能从毫秒级跳到秒级。但光建索引不够，容易踩的坑是：
-
user_id存的是字符串（如"507f1f77bcf86cd799439011"），但索引是按ObjectId建的 → 查询时类型不匹配，索引失效 - 索引建在已有大量数据之后 → 创建过程阻塞写入，且可能因内存不足失败
- 只建了单字段索引，但实际查的是
{ user_id: ..., status: "approved" }→ 应该建复合索引db.comments.createIndex({ user_id: 1, status: 1 })
正确做法：插入第一批数据前，就执行 db.comments.createIndex({ user_id: 1 })；若字段值来自前端传入的字符串 ID，后端必须先用 new ObjectId(str) 转换再写入。
避免 N+1，用 $lookup 或批量查询代替循环 findOne
查某个用户全部评论时，别这么写：
const user = db.users.findOne({ _id: userId });
const comments = user.comment_ids.map(id => db.comments.findOne({ _id: id }));
这会产生几十上百次 round-trip，连接数暴涨，延迟叠加。可行方案有两个：
- 用聚合管道
$lookup一次性关联（适合“查用户+最近 20 条评论”这类明确范围的场景） - 更通用的做法：先查出用户，再用
db.comments.find({ user_id: userId }).sort({ created_at: -1 }).limit(20)单次查询 —— 关键是确保user_id和排序字段已建好复合索引，例如db.comments.createIndex({ user_id: 1, created_at: -1 })
注意：$lookup 在分页场景下性能不如原生查询，尤其当“多”侧数据极大时，聚合阶段容易 OOM；它更适合做视图抽象或轻量 JOIN。
分页不能只靠 skip/limit，得用基于游标的方案
对某用户的全部评论做“第 100 页，每页 20 条”，用 .skip(1980).limit(20) 是灾难性的：MongoDB 得从头扫过近 2000 条才返回结果，CPU 和磁盘 IO 都吃紧。
真实可用的分页方式是游标（cursor-based pagination）：
- 第一页：
db.comments.find({ user_id: userId }).sort({ created_at: -1 }).limit(20) - 后续页：取上一页最后一条的
created_at和_id，发查询db.comments.find({ user_id: userId, created_at: { $lt: last_time }, _id: { $lt: last_id } }).sort({ created_at: -1 }).limit(20)
这个方案要求排序字段严格唯一或组合唯一（created_at 可能重复，所以补上 _id 作为第二排序键），且对应字段必须有索引。漏掉索引或用错排序方向（比如 sort({ created_at: 1 }) 却用 $lt），分页会漏数据或重复。
最易被忽略的一点：游标分页依赖“单调递增且不可变”的排序依据。如果业务允许修改评论时间（created_at），那这个字段就不能单独用作游标锚点，得换成服务端生成的、只读的序列号字段（如 seq_no: NumberLong）并建索引。
