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