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的锁时间限制，其实是系统在告诉你：这个逻辑不该放在这里做。
