MongoDB事务快照内存占用取决于被修改文档的原始大小而非修改量，一个10MB文档updateOne一次即占10MB内存，循环100次达1GB；需调低maxTransactionLifetimeMinutes至2–5分钟、禁用forEach式遍历、改用updateMany或分批事务，并监控currentActive×平均文档大小是否超0.7×wiredTigerCacheSizeGB。
事务快照内存到底占多少
事务不是“改几条就占几条内存”，而是为每个被修改的文档保存一份完整旧版本快照。一个 10MB 的日志文档在事务里 updateOne 一次，就额外吃掉 10MB 内存；循环 updateOne 100 次，就是 1GB 快照——哪怕只改了字段值。WiredTiger 缓存（wiredTigerCacheSizeGB）撑不住时，OS 就触发 OOM Killer 杀 mongod。
maxTransactionLifetimeMinutes 必须调低
默认 60 分钟太危险。长事务空闲不动，快照却一直挂着不释放，内存只增不减。线上集群应压到 2–5 分钟：
- 配置文件改法：
setParameter: maxTransactionLifetimeMinutes: 2，加在mongod.conf的setParameter节点下 - 热生效命令：
db.adminCommand({setParameter: 1, maxTransactionLifetimeMinutes: 2}) - 注意：这个参数只管“空闲超时”，不管事务内慢操作；如果 updateMany 本身要跑 3 分钟，它照样能活过 2 分钟
别用 forEach 包事务，改用 updateMany 或分批
db.collection.find().forEach(doc => db.collection.updateOne(...)) 是典型陷阱：每轮 updateOne 都向事务快照追加副本，N 次 = N 份冗余。
- 能单条完成，就用
updateMany：db.orders.updateMany({status: "pending"}, {$set: {status: "processing"}}) - 逻辑复杂必须循环？拆成多个独立事务，每批 ≤ 500 文档（若单文档平均 2MB，则每批上限得降到 200）
- 绝对禁用
find().toArray()进事务——整个结果集先加载进内存，再塞进快照，等于双倍吃内存
监控 transactionMetrics 别等 OOM 才发现
currentActive 和 currentInactive 是最早暴露问题的指标，比看 top 或 free -m 更灵敏：
- 查法：
db.runCommand({serverStatus: 1}).metrics.transaction - 预警线：
currentActive × 平均文档大小 > 0.7 × wiredTigerCacheSizeGB × 1024³（单位统一为字节） - 一旦
currentActive持续 ≥ 3 且currentInactive不下降，说明事务卡在 commit/rollback，快照正堆积
事务最危险的不是“大”，是“看不见”——日志里写着 “transaction completed”，但 wiredTigerCacheSizeGB 可能还在涨。盯住快照实际占用，而不是事务表面行数。
