事务快照内存占用取决于被修改文档原始版本总大小，而非事务日志完成标记；单次updateOne修改15MB文档即占用15MB快照内存，多次操作线性累加，超限触发TransactionTooLarge或OOM Killer。
事务快照内存到底占多少
事务内存不是看日志里“transaction completed”就完事的——它取决于快照中所有被修改文档的原始版本总大小。一个updateOne改掉一条含15MB二进制字段的文档，快照就立刻吃掉15MB；100次这样的操作，就是1.5GB，跟事务是否“小”完全无关。
WiredTiger默认事务内存上限是100MB（transactionLifetimeLimitSeconds不控制这个），超限直接中止并报错TransactionTooLarge；但更危险的是没超限却把wiredTigerCacheSizeGB撑满，触发OS级OOM Killer杀mongod进程。
别用find().forEach()包事务
这是线上最常见OOM诱因：表面写的是“逐条更新”，实际每轮updateOne都在快照里追加一份旧文档副本，N次就是N份冗余内存。
- ❌ 错误写法：
session.startTransaction(); db.orders.find({status: "pending"}).forEach(doc => { db.orders.updateOne({_id: doc._id}, {$set: {status: "processing"}}); }); session.commitTransaction(); - ✅ 正确替代：
db.orders.updateMany({status: "pending"}, {$set: {status: "processing"}})—— 单次操作，只存一份快照 - ⚠️ 逻辑复杂必须分步？拆成多个独立事务，每批严格控制在
500文档以内（单文档越大，这个数越要往下调）
硬限事务生命周期，但得懂它限的是什么
maxTransactionLifetimeMinutes设太宽（默认60）等于放任内存缓慢堆积；设太紧又可能误杀正常长事务。关键是它只限制“空闲时间”，不卡慢查询本身。
- 推荐值：
2分钟（即120秒），线上集群可通过热命令调整：db.adminCommand({setParameter: 1, maxTransactionLifetimeMinutes: 2}) - 注意：如果事务内有未优化的
find().sort().limit()或缺少索引的countDocuments()，照样会因数据集膨胀OOM——限的是挂起时间，不是执行时间 - 搭配监控：
db.runCommand({serverStatus: 1}).metrics.transaction里盯currentActive和currentInactive，持续>3且currentInactive不降，说明事务卡在提交/回滚环节，快照正疯涨
监控阈值比看top更早预警
等top显示mongod占满内存时，OOM往往已发生。真正有效的信号藏在引擎指标里：
- 查缓存占用：
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]，超过0.95 * wiredTigerCacheSizeGB * 1024^3就得干预 - 算快照风险：
currentActive × 平均文档大小 > 0.7 × wiredTigerCacheSizeGB × 1024^3→ 立刻告警（平均文档大小可从db.collection.stats()的avgObjSize估算） - 脏数据占比超20%？说明WiredTiger清理线程跟不上写入节奏，可临时调高
eviction=(threads_max=8,threads_min=4)，但仅限副本集4.0+
事务真正的内存陷阱不在“改了多少条”，而在“每条有多大”和“改完没及时交”。别信日志，盯住wiredTigerCacheSizeGB和currentActive这两个数。
