MongoDB 更新大文档卡住是因WiredTiger引擎触发整块BSON重写，导致I/O、CPU和journal压力激增；应按“极少查询过滤、持续增长、允许异步”三原则判断是否拆分，优先用refId引用替代嵌入。
更新大文档时为什么卡住？WiredTiger 的写放大效应
不是 MongoDB 故意慢，而是 WiredTiger 引擎在更新一个接近 16MB 的文档时，会触发整块 BSON 数据的重写、压缩、校验和写入日志——哪怕只改了 status 字段的一个字符。这导致磁盘 I/O 暴增、journal 写入延迟升高、CPU 压力陡升，最终表现为 updateOne 耗时从毫秒级跳到秒级，甚至超时。
典型现象包括：
- 监控中
wt_checkpoint频率下降，wiredTiger.cache.dirty持续高于 20% - 日志里频繁出现
slow update记录，numYields显著上升 - 同一文档被高频更新时，
writeConflicts开始非零
拆成子集合前，先确认是不是真该拆
盲目拆分反而引入 JOIN 成本和事务复杂度。先问三个问题：
- 这个大字段（比如
logs数组或history嵌套对象）是否**极少被查询条件过滤**？如果是，它就不该和主文档耦合 - 它是否**随时间持续增长**（如用户操作日志、设备上报记录）？增长型字段天然不适合嵌入
- 业务上是否允许它**异步写入或延迟可见**？子集合更新可独立于主文档事务
满足其中两条，就值得拆；三条都满足，基本就是“必拆”。
怎么拆：用 refId 替代嵌入，保留语义一致性
不推荐用 ObjectId 字符串硬编码关联，而应统一用带类型标识的引用字段。例如：
// 原结构（危险）
{
_id: ObjectId("..."),
userId: "U123",
profile: { ... },
activityLogs: [ { ts: ..., action: "click", data: {...} }, ... ] // 已达 12MB
}
// 拆分后（安全）
// 主文档（保持轻量 & 高频读）
{
_id: ObjectId("..."),
userId: "U123",
profile: { ... },
latestActivityAt: ISODate("...")
}
// 子集合 activity_logs
{
_id: ObjectId("..."),
refType: "user",
refId: "U123",
ts: ISODate("..."),
action: "click",
data: { ... }
}
关键点：
-
refId必须建索引：db.activity_logs.createIndex({refType: 1, refId: 1, ts: -1}) - 避免在子集合里存冗余字段（如重复
userId），用refId+refType足够路由 - 如果需原子性（如“创建用户同时写首条日志”），用多文档事务包裹主文档插入 + 子集合插入
容易被忽略的坑：分页与聚合逻辑迁移
拆完后，原来 find({userId: "U123"}).sort({ts: -1}).limit(10) 这种写法失效了。必须重构为：
- 分页查日志：直接查
activity_logs，不再依赖主文档 - 带主文档信息的聚合：用
$lookup关联，但注意pipeline中限制子集合匹配数量，否则内存爆掉 - 避免在应用层做两次查询再 merge —— 网络延迟 + GC 压力可能比原来更差
最隐蔽的陷阱是：开发时用小数据测试看不出问题，上线后用户行为日志一涨，$lookup 的 from 集合缓存失效，瞬间拖垮整个聚合管道。
