不能直接调 transactionlifetimelimitseconds 解决事务超时问题，该参数是服务端全局硬上限（默认60秒），强行调大易致连接池雪崩、跨分片事务挂起、oplog压力增大；应优先实测耗时后合理设置客户端 maxtimems，并排查索引缺失、http阻塞等根本原因。
不能直接调 transactionLifetimeLimitSeconds 解决事务超时问题。 这个参数是 MongoDB 内部协调器的全局硬上限（默认 60 秒），它不是给应用层用的 timeout 配置项，改了反而可能掩盖真实瓶颈、引发连接池雪崩或跨分片事务挂起。
为什么改 transactionLifetimeLimitSeconds 是危险操作
这个参数控制的是 mongos 或 coordinator shard 上事务上下文的最大存活时间，一旦超限，服务端会强制 abort 并清理所有关联锁和会话状态。但它不参与客户端超时逻辑，也不影响 maxTimeMS 的行为。强行调大（比如设成 300 秒）会导致：
- 长事务持续占住连接和内存，高并发下快速耗尽
maxConns - 跨分片事务在 prepare 阶段卡住时，不会提前失败，而是等满 300 秒才报
TransactionTooOld，排查难度陡增 - 副本集内 oplog 压力增大，secondary 节点同步延迟升高
- 该参数需重启 mongod/mongos 才生效，生产环境不可热更新
真正该调什么：优先用 maxTimeMS + 实测耗时
maxTimeMS 是唯一可由客户端控制、且能被事务主操作实际响应的超时参数。但必须按实测来设，不能拍脑袋：
- 在测试环境用真实数据量 + 真实业务逻辑跑一次完整事务，记录从
session.startTransaction()到session.commitTransaction()的总耗时 - 取该耗时 ×1.5 作为
maxTimeMS值（例如实测 8 秒 → 设 12000） - Node.js 驱动中必须在
startTransaction({ maxTimeMS: 12000 })里传入，事后调session.transactionOptions无效 - Java 驱动同理，要用
TransactionOptions.builder().maxCommitTime(12, TimeUnit.SECONDS)
跨分片事务里 maxTimeMS 其实没用
在分片集群中，maxTimeMS 只约束 coordinator shard 上的主操作执行时间，完全不管 prepare 广播、其他分片响应、两阶段提交网络往返这些开销。你设了 5 秒，事务却卡在某个分片上等锁 20 秒，最后还是报 TransactionTooOld —— 此时靠调参无解，得从架构入手：
- 检查各分片的
txnNumber是否一致：连到每个 shard 执行db.runCommand({getLastError: 1})，比对返回里的txnNumber - 逐个执行
db.adminCommand({refreshLogicalSessionCacheNow: 1})强制刷新缓存 - 把
logicalSessionCacheRefreshPeriodMS从默认 300000 改为 30000，并滚动重启分片确认生效 - 避开
sh.setShardingBalancer()等管理命令高峰期发起事务
事务超时从来不是单点参数问题。真正卡住的往往是没索引的查询、事务里混了 HTTP 调用、或者写操作带 upsert: true 却没建唯一索引——这些细节比调参重要得多。
