大事务在MongoDB 6.0分片集群中会直接触发WT_CACHE_FULL、OOM Killer杀进程并拖垮节点，根本原因是WiredTiger为所有读写文档保留完整旧版本快照，内存占用取决于“碰过哪些文档及其原始体积”，而非修改字段多少；需严格限制transactionLifetimeLimitSeconds（30–45秒）和maxTransactionLifetimeMinutes（2–5分钟），并强制try/catch/finally中abortTransaction、禁用forEach循环更新、分批≤500条且优先用updateMany。
大事务在 MongoDB 6.0 分片集群里不是“慢一点”的问题，而是直接触发 WT_CACHE_FULL、OOM Killer 杀进程、甚至拖垮整个 mongos 和 shard 节点的高危行为。根本原因在于 WiredTiger 必须为事务中所有被读/写的文档保留完整旧版本快照——改一个字段，内存就吃掉整篇文档大小。
为什么 updateOne 100 次会占 1GB 内存？
事务快照内存占用不看“改了多少”，而看“碰过哪些文档及其原始体积”。一个平均 2MB 的订单文档，在事务里循环 updateOne 500 次，WiredTiger 就要缓存 500 × 2MB = 1GB 快照数据，哪怕每次只更新 status 字段。
- 不能依赖
find().toArray()+ 循环操作：整个结果集先加载进内存，再逐条进快照，等于双倍吃 RAM -
forEach包事务是典型陷阱：每轮updateOne都新增一份快照副本，N 次 = N 份冗余 - 单文档越大、事务内操作越分散（如跨多个集合读写），快照碎片越严重，eviction 效率越低
必须调的两个超时参数：transactionLifetimeLimitSeconds 和 maxTransactionLifetimeMinutes
这两个参数分工明确，缺一不可：
-
transactionLifetimeLimitSeconds（mongos 级）：控制从发起startTransaction()到下一次操作（commit/abort）的最大间隔，默认 60 秒；设为 30–45 秒较稳妥，超过即报TransactionTooOld -
maxTransactionLifetimeMinutes（mongod 级）：控制事务空闲状态最长存活时间，默认 60 分钟；生产环境必须压到 2–5 分钟，否则快照长期悬空不释放 - 两者都需通过配置文件预设（
mongos.conf和mongod.conf），运行时用db.adminCommand({setParameter: 1, ...})可热生效，但不推荐线上频繁调整
应用层必须做的三件事
参数只是兜底，真正掐断内存泄漏源头得靠代码习惯：
- 所有事务块强制用
try/catch/finally包裹，finally中无条件调session.abortTransaction()（即使已 commit 也安全） - 事务内禁止任何阻塞 I/O：HTTP 调用、
sleep()、文件读写等必须前置完成，结果存变量再进事务 - 批量操作必须分批：单事务 ≤ 500 条（若平均文档 > 2MB，则需进一步压缩到 200 条以内），优先用
updateMany替代循环updateOne
怎么确认内存真被事务占住了？
别等 OOM 才行动。盯住这三个指标比看 free -m 有效得多：
-
db.runCommand({serverStatus: 1}).wiredTiger.cache["bytes currently in the cache"]/maximum bytes configured持续 > 85% 是危险信号 -
db.runCommand({serverStatus: 1}).metrics.transaction.currentActive× 预估平均文档大小 > 0.7 ×wiredTigerCacheSizeGB× 1024³（单位字节）就要预警 -
db.currentOp({ "secs_running": { "$gt": 10 }, "transactionState": "inProgress" })返回大量长时事务，说明有未终结会话在 hold 快照
最隐蔽的问题是：日志显示事务“已提交”，但 currentActive 不降、cache 占用不回落——这意味着客户端连接还挂着，WiredTiger 仍认为事务处于“可能 rollback”状态，快照锁死不动。
