mongodb事务默认超时60秒，由服务端参数transactionlifetimelimitseconds控制，超时后静默回滚并返回transactiontooold等错误；该参数需在mongod中配置，maxtimems仅限制单次操作，无法延长事务整体寿命。
不能只靠 maxTimeMS 延长事务寿命——它只管单个操作，不管整个事务。 真正控制事务“活多久”的是服务端参数 transactionLifetimeLimitSeconds，默认 60 秒，超时后静默回滚，客户端看到的是 TransactionTooOld 或 NoSuchTransaction 错误，而不是明确的超时异常。
怎么查和改 transactionLifetimeLimitSeconds
这个值是服务端硬限制，必须在 mongod 进程里设置，驱动层传 maxTimeMS 完全无效。
- 查当前值：
db.adminCommand({getParameter: 1, transactionLifetimeLimitSeconds: 1}) - 临时调高（重启不保留）：
db.adminCommand({setParameter: 1, transactionLifetimeLimitSeconds: 120}) - 永久生效：加到
/etc/mongod.conf的setParameter区块里，例如：setParameter: { transactionLifetimeLimitSeconds: 120 } - 分片集群要同步改所有分片 + config server 的该参数，漏一个就可能报
IllegalOperation
maxTimeMS 在事务里到底起什么作用
它只约束事务内**单次操作**（比如一次 updateMany() 或 find()）的执行时长，不是整个事务生命周期。设了也没法绕过 60 秒大限。
- Node.js 驱动中必须在
session.startTransaction({ maxTimeMS: 12000 })里传，事后调session.setTransactionOptions()无效 - 如果某次
update自身耗时超maxTimeMS，会直接报MaxTimeMSExpired，事务还没到 60 秒就被中断 - 常见踩坑：把
maxTimeMS设成 300000（5 分钟），误以为能撑住长事务——其实只是让单次操作更耐扛，但 60 秒一到，整个事务照样被服务端清理
为什么调高 transactionLifetimeLimitSeconds 要谨慎
超过 120 秒就得掂量真实代价，不是数字越大越稳。
- WiredTiger 缓存压力会随事务时长线性增长，长时间未提交事务可能触发
WriteConflict或直接被中止 - oplog 条目变多、变碎，主从延迟风险上升，尤其在写密集场景
- 锁持有时间拉长，
maxTransactionLockRequestTimeoutMillis（默认 5ms）更容易触达，引发大量WriteConflict报错 - 云服务如 MongoDB Atlas 通常锁死该参数，或仅允许小幅上调，调太高可能被平台自动干预
真正卡住事务的，往往不是时间，而是没走索引的查询、跨分片协调开销、或事务里混了 HTTP 调用。先用 db.currentOp({ "secs_running": { "$gt": 5 } }) 定位真瓶颈，再决定要不要动 transactionLifetimeLimitSeconds —— 大多数情况，拆逻辑、加索引、移出异步操作，比硬抬时限更可靠。
