WiredTiger事务锁超时由transactionLifetimeLimitSeconds和引擎MVCC机制共同决定，非MongoDB硬编码；默认60秒超时abort，但cache overflow或stable_timestamp滞后可能提前触发失败。

WiredTiger事务锁超时不是MongoDB硬编码限制，而是由transactionLifetimeLimitSeconds和底层引擎行为共同决定的

MongoDB本身不直接“限制锁时间”，但会强制中止长时间运行的事务——根本原因是WiredTiger存储引擎无法无限期保留多版本数据（MVCC），否则内存和磁盘开销会失控。事务一旦开始，WiredTiger就必须为它维护一个一致的快照视图；这个视图依赖oldest_timestamp来判断哪些历史版本还能被读到、哪些可以安全清理。如果事务卡住不动，oldest_timestamp就无法推进，旧版本堆积，缓存迅速被占满，甚至触发OOM或写阻塞。

• transactionLifetimeLimitSeconds默认是60秒（4.2+），超过即自动abort，这是最直观的“锁时间上限”
• 即使你手动设大（比如300），WiredTiger仍可能因cache overflow提前报错：WT_CACHE_FULL: cache overflow
• 副本集场景下，secondary同步延迟也会拖慢stable_timestamp推进，间接加剧主节点压力

哪些操作最容易触发锁超时？

不是所有事务都等价。WiredTiger锁持有时间取决于事务内实际修改/读取的数据量与持续时间，而非语句条数。以下场景高频踩坑：

• 在事务里做find().forEach()遍历并逐条updateOne()——每条update都延长锁持有，且无法批量提交
• 事务中调用外部HTTP服务或sleep(1000)——锁全程不释放，WiredTiger干等
• 对无索引字段执行updateMany({status: "pending"}, {$set: {processed: true}})——全表扫描+逐文档加锁，极易超时
• 在高并发下开启事务后，未及时commitTransaction()或abortTransaction()，session悬空

怎么查是不是锁超时导致失败？

错误日志里不会直接说“锁超时”，得看组合线索：

• 应用层报错含TransactionTooOld或ExceededTimeLimit——基本就是transactionLifetimeLimitSeconds生效了
• mongod日志出现WT_CACHE_FULL或WT_ROLLBACK——说明WiredTiger已主动终止事务保命
• db.currentOp({ "secs_running": { "$gt": 5 } })能看到长时间运行的事务，结合secs_running和numYields判断是否卡在I/O或锁等待
• 监控serverStatus.metrics.transaction下的aborted和timedOut计数突增

绕过锁时间限制不是调大参数就完事

盲目增大transactionLifetimeLimitSeconds只是掩耳盗铃。真正要做的，是让事务“短、快、轻”：

• 把大事务拆成多个小事务，用幂等ID+状态机控制进度，而不是包在一个session里干到底
• 读操作尽量移出事务——WiredTiger对只读事务几乎不加写锁，但一旦混入写操作，整个快照生命周期就被拉长
• 确保所有更新字段都有高效索引，避免docsExamined >> nMatched这类低效扫描
• 禁用不必要的readConcern: "snapshot"——它会强制WiredTiger保留更老的版本，加剧内存压力

事务本质是协调成本，WiredTiger的锁时间限制，其实是系统在告诉你：这个逻辑不该放在这里做。