调大maxTransactionLockRequestTimeoutMillis仅掩盖问题，不能根治锁冲突；应通过db.currentOp定位活锁、统一操作顺序、缩短锁持有时间来解决。
直接调 maxTransactionLockRequestTimeoutMillis 只能缓解表象，不能解决锁等待的根本原因；它默认 5 毫秒，太短，但盲目拉长到几秒反而会掩盖死锁、逻辑错序和外部阻塞等真实问题。
为什么锁等待超时不是“加时间”就能解决
事务内写操作（如 updateOne）在获取文档锁失败时，会阻塞等待最多 maxTransactionLockRequestTimeoutMillis 毫秒，超时即抛 WriteConflict。但这不是数据库“卡了”，而是两个事务以不同顺序争抢同一组文档——比如事务 A 先改订单再改用户，事务 B 反过来先改用户再改订单，WiredTiger 不会自动回滚任一事务，只会让后到者等满超时后报错。
常见错误现象包括：WT_ROLLBACK 日志频繁出现、lock.currentQueue.writers 持续增长、db.currentOp() 显示大量 "waitingForLock": true 的活跃事务。
此时调大 maxTransactionLockRequestTimeoutMillis，只是让冲突更晚暴露，甚至导致连接堆积、响应延迟毛刺放大。
先定位真凶：用 db.currentOp 查活锁和慢事务
别猜，直接看正在发生什么。运行以下命令快速筛出可疑事务：
db.currentOp({
"secs_running": { "$gt": 2 },
"active": true,
"waitingForLock": true
})
重点关注返回中的 secs_running、microsecs_running 和 ns（集合名），再结合 command 字段还原操作序列。
- 若多个事务都卡在同一个
ns（如mydb.orders）且secs_running接近，大概率是操作顺序不一致引发的活锁 - 若某个事务
secs_running很小但waitingForLock为 true，说明它正被另一个已持锁事务阻塞，需顺藤摸瓜查那个“持锁者”的secs_running - 若事务里出现
http、fetch、eval或长时间find，基本可断定是外部调用或无索引扫描拖慢了锁释放
怎么安全调整 maxTransactionLockRequestTimeoutMillis
如果确认是极少数场景下因瞬时锁竞争激烈（非逻辑缺陷），且已压测验证过影响，才考虑微调。生产环境建议只设到 100–300 毫秒，绝不超过 1 秒。
有三种方式，优先级从高到低：
- 在线动态修改（仅限副本集主节点）：
db.adminCommand({ setParameter: 1, maxTransactionLockRequestTimeoutMillis: 300 }) - 启动参数（重启生效）：
mongod --setParameter maxTransactionLockRequestTimeoutMillis=300 - 配置文件（
/etc/mongod.conf）：setParameter: maxTransactionLockRequestTimeoutMillis=300
注意：maxTransactionLockRequestTimeoutMillis 和 transactionLifetimeLimitSeconds 无关，前者管单次锁等待，后者管整个事务生命周期；也不能替代客户端 maxTimeMS，后者控制的是事务总耗时上限。
真正该做的：砍掉锁持有时间本身
锁等待超时是症状，锁持有太久才是病根。优化方向非常明确：
- 事务内禁止任何非数据库操作：删掉 HTTP 调用、JSON 解析、PDF 生成等，这些必须移到事务外
- 所有跨文档更新强制统一顺序：例如对订单相关操作，先按
order_id升序排序所有待更新文档，再批量执行 - 用
bulkWrite()替代循环updateOne()，减少网络往返和事务内 round-trip 次数 - 避免
updateMany()或无条件find()：必须带精准索引支撑的查询条件，并用limit(N)控制单次操作范围 - 检查是否真需要事务：单文档原子更新（如
inc、set）完全不需要事务，也无锁等待风险
最隐蔽的坑是那些没报错、没超时、但一直拿着锁不放的“半死事务”——它们可能卡在网络读取、第三方重试或未捕获异常后的 finally 缺失。务必确保每个 session.startTransaction() 都配对 commitTransaction() 或 abortTransaction()，Node.js 中慎用裸事务，优先走 withTransaction()。
