事务超时由服务端参数transactionLifetimeLimitSeconds控制，默认60秒，maxTimeMS仅作用于单操作；需验证版本≥4.2且为副本集/分片集群，修改后仅影响新事务，设过大易致资源耗尽与排查困难。
事务超时不是客户端能改的，得动服务端参数 transactionLifetimeLimitSeconds。默认 60 秒是硬限制，maxTimeMS 对整个事务生命周期完全无效，只管单个操作。
怎么确认当前值和版本支持
先别急着改，很多问题出在“以为改了，其实没生效”。必须验证两件事：
-
db.version()必须 ≥ 4.2；4.0 不支持该参数，单机模式也不支持事务 - 运行
db.adminCommand({ getParameter: 1, transactionLifetimeLimitSeconds: 1 })，如果返回undefined，说明要么版本低，要么没在副本集或分片集群中（rs.status()或sh.status()确认） - 云数据库如 MongoDB Atlas、阿里云 MongoDB 通常锁定该参数，控制台搜不到就只能提工单
动态修改的正确姿势和限制
有权限且环境支持时，用 adminCommand 修改最常用，但注意它不重启生效，也只对新事务起作用：
- 执行命令：
db.adminCommand({ setParameter: 1, transactionLifetimeLimitSeconds: 120 }) - 返回
{ "ok": 1 }才算成功；失败常见原因是没clusterAdmin权限 - 已运行中的事务仍按旧值倒计时，不会被“续命”
- 分片集群下，所有 shard 和 mongos 的该参数都会影响最终行为——木桶效应，取最小值
为什么设大了反而更危险
调到 300 秒不是“保险”，而是埋雷。这个参数延长的是事务上下文存活时间，不是性能优化：
- 长事务持续占 session、锁、连接和内存，高并发下容易快速耗尽
maxConns - 跨分片事务卡在 prepare 阶段时，不会提前失败，而是死等到 300 秒才报
TransactionTooOld，排查成本翻倍 - oplog 堆积加剧，secondary 同步延迟升高，可能触发复制中断
- 真正卡住的原因常是锁等待、索引缺失或网络分区，
transactionLifetimeLimitSeconds完全不干预这些
比调参更关键的三件事
多数人盯着这个参数，却漏掉真正该做的：
- 实测业务典型事务耗时：从
session.startTransaction()到commitTransaction()全链路压测，再乘以 1.5 倍设新值（比如实测 42 秒 → 设 60–70 秒） - 同步检查
maxTransactionLockRequestTimeoutMillis：它控制锁等待上限，默认 5 秒，和事务超时无关；若写冲突频繁，可设为 30000，但要配合适当索引 - 驱动层加兜底：Node.js 中用
Promise.race([transactionPromise, setTimeout(…)])，Python 里用with timeout(…)，防止客户端逻辑阻塞导致事务空悬
这个参数本质是保底线，不是提速器。真卡住了，先查 db.currentOp()、看锁、建索引、拆逻辑，最后才考虑调它——而且永远留一截余量，别拉满。
