事务快照保留时间由transactionLifetimeLimitSeconds控制，MongoDB 4.4默认60秒，超时自动中止并清理；该值需≥maxTimeMS，建议根据业务调整至略高于典型事务耗时，并在finally中显式abort以防止隐式长事务。
事务快照保留时间由 transactionLifetimeLimitSeconds 控制
MongoDB 4.4 默认将事务最长存活时间设为 60 秒，超时后服务端自动中止并清理关联快照。这个参数直接决定 WiredTiger 引擎需为未提交事务维持多旧的快照——快照越老，内存中保留的旧版本数据（包括 MVCC 版本链）就越多。
实操建议：
- 若业务中绝大多数事务在 5 秒内完成，可安全下调至
transactionLifetimeLimitSeconds: 10，大幅减少长事务意外挂起导致的快照堆积 - 该值不能低于客户端设置的
maxTimeMS，否则服务端会在客户端超时前强制终止事务，引发TransactionTooOld或NoSuchTransaction - 修改需重启 mongod 或通过
setParameter命令动态调整（仅限 4.4+ 副本集主节点）：db.adminCommand({ setParameter: 1, transactionLifetimeLimitSeconds: 10 })
避免隐式长事务：别让 session.startTransaction() 后不提交也不终止
常见错误是调用 session.startTransaction() 后，因异常未走到 commitTransaction() 或 abortTransaction()，导致会话保持打开状态。WiredTiger 会持续保留该事务开始时刻的快照，直到会话超时（默认 30 分钟）或连接断开。
关键点：
- 必须在
try/catch/finally的finally块中显式调用abortTransaction()，哪怕你预期只走commit - Node.js 驱动中，
withTransaction()自动处理收尾，但自定义事务逻辑（如分步写入+条件判断）必须手动兜底 - 可通过
db.currentOp({ "secs_running": { "$gt": 5 } })查看运行超 5 秒的事务，定位泄漏点
写操作密集场景下，readConcern: "snapshot" 与事务快照相互影响
单独使用 readConcern: "snapshot"（非事务内）也会触发快照创建，且其生命周期独立于事务参数——它受 snapshotMaxTimeMS（默认 60 秒）控制。若同时大量使用快照读 + 长事务，内存压力会叠加。
优化方向：
- 非跨文档强一致性场景，优先用
readConcern: "majority"替代"snapshot" - 确认是否真需要事务级隔离：单文档原子更新（如
updateOne）无需事务，也无快照开销 - 监控
globalLock.totalTimeMicros和wiredTiger.cache.maximum bytes configured，当 cache 使用率持续 >85% 且伴随cache overflow日志时，快照可能是元凶
真正难处理的是那些“半死不活”的事务：没报错、没提交、也没被 kill，只是卡在应用层某次网络等待或锁竞争里。它们不会出现在慢查询日志，却悄悄拖住快照释放。上线前务必在压测中注入随机失败，验证事务收口逻辑是否健壮。
