MongoDB 6.0将transactionLifetimeLimitSeconds默认值由60秒降为30秒，升级后未显式配置该参数的部署将自动生效新值，可能导致长事务报TransactionTooOld错误；需通过db.adminCommand动态调整或写入配置文件，并同步优化wiredTigerCacheSizeGB等关联参数。
transactionLifetimeLimitSeconds 默认值变了，别直接照搬旧配置
MongoDB 6.0 把 transactionLifetimeLimitSeconds 默认值从 60 秒降为 30 秒。如果你是从 4.4/5.x 升级上来的，没手动设过这个参数，那事务超时行为已经变了——短事务更安全，但原来能跑完的长事务可能突然报 TransactionTooOld 错误。
用 db.adminCommand 动态调整，但不能低于 10 秒
运行时修改最常用方式是：
db.adminCommand({ "setParameter": 1, "transactionLifetimeLimitSeconds": 45 })
注意几点：
- 该命令只对当前 mongod 实例生效，重启后失效（除非写进配置文件）
- 值设成
10是硬下限；低于它会触发频繁的TransactionTooOld，不是所有业务逻辑能容忍 - 设太高（比如 120）会放大 WT_ROLLBACK 风险，尤其当
wiredTigerCacheSizeGB没同步调优时 - 分片集群中，需在每个 mongod（包括 config server 和 shard 节点）上分别执行，mongos 不接受该参数
写进配置文件才真正“落地”，且要配对调优
生产环境建议写进 /etc/mongod.conf 的 setParameter 区块：
setParameter: transactionLifetimeLimitSeconds: 45
但光改这一个参数不够，必须同步检查：
-
wiredTigerCacheSizeGB：默认是物理内存 50%，高并发事务下常不够，实测 64GB 机器设为 42GB 比默认 32GB 提升约 22% TPS -
eviction_target和eviction_trigger：默认 80% / 90%，若缓存压力大，需下调eviction_target避免脏页堆积 - 确认没有其他地方（比如应用层连接池）隐式延长了事务生命周期，比如未及时
session.endSession()
怎么确认改成功了？别只看命令返回
db.adminCommand({ "getParameter": 1, "transactionLifetimeLimitSeconds": 1 }) 能查当前值，但更重要的是观察实际行为：
- 查
serverStatus.metrics.transaction.currentInactive：持续 > 5 说明有事务卡在 prepare 阶段，可能是超时前就卡住了 - 监控日志里是否频繁出现
TransactionTooOld或WT_ROLLBACK - 用
db.currentOp({ "secs_running": { "$gt": 30 } })定期采样，看有没有“慢事务”漏网
改参数只是手段，核心是让事务生命周期匹配业务真实耗时——超时不是越短越好，而是要比最长正常路径多留 2–3 秒缓冲，又不能长到拖垮缓存和锁竞争。
