事务卡在“waitingForLock: true”是因为文档级锁竞争，且默认锁等待上限仅5毫秒，超时即抛WriteConflict；需通过服务端参数maxTransactionLockRequestTimeoutMillis调大该值，并优化事务设计以减少锁争用。
为什么事务卡在“waitingForLock: true”
事务没报错、也没超时，但就是不动，db.currentOp() 显示 waitingForLock: true，说明它正在等别的事务或操作释放锁——不是网络或配置问题，是典型的锁竞争。MongoDB 事务对写操作加的是**文档级锁**，但锁获取有默认等待上限：maxTransactionLockRequestTimeoutMillis，默认仅 5 毫秒。一旦等不到，直接抛 WriteConflict，而不是继续挂起。
- 这个 5ms 是服务端硬限制，和
maxTimeMS或transactionLifetimeLimitSeconds完全无关 - 它只作用于“尝试获取锁”这一步，不包含执行时间、网络延迟或事务空闲时间
- 常见于高并发更新同一组文档（如用户余额、库存计数器），或事务内顺序反了（A 先改 X 再改 Y，B 先改 Y 再改 X）
怎么调大锁等待时间
必须改服务端参数，客户端驱动无法覆盖。有三种方式，优先级从高到低：
- 运行时动态设置（需
clusterAdmin权限）：db.adminCommand({ setParameter: 1, maxTransactionLockRequestTimeoutMillis: 3000 }) - 启动参数（推荐用于生产）：
mongod --setParameter maxTransactionLockRequestTimeoutMillis=3000 - 配置文件（
/etc/mongod.conf）：setParameter: maxTransactionLockRequestTimeoutMillis=3000
注意：设成 3000 毫秒（3 秒）是较稳妥的起点；超过 5000 毫秒要谨慎，可能掩盖设计问题而非解决它。
比调参数更关键的是避免锁等待
延长等待时间只是兜底，真正要减少 waitingForLock，得从应用逻辑入手：
- 把长事务拆短：单个事务修改不超过 1000 文档，避免跨集合、跨分片操作
- 统一访问顺序：所有事务按相同字段顺序更新文档（比如始终先
updateOne({ type: "order" })，再updateOne({ type: "inventory" })） - 去掉事务里非数据库操作：HTTP 调用、文件读写、复杂计算——这些不占锁，但拖长持有锁的时间
- 确认索引覆盖：
updateOne的filter字段必须有索引，否则全表扫描会锁住大量无关文档
锁等待问题容易被误判的点
看到 waitingForLock: true 就去调参，常掉进两个坑：
- 误以为是事务超时：其实
MaxTimeMSExpired和WriteConflict是两类错误，前者来自maxTimeMS，后者来自锁等待失败 - 在单机模式下白忙活：
maxTransactionLockRequestTimeoutMillis在副本集或分片集群才生效，单机mongod不支持该参数 - 没检查真实瓶颈：用
db.currentOp({ "secs_running": { "$gt": 2 } })看是否真在等锁，还是执行本身慢（waitingForLock: false但secs_running高）
锁等待时间不是越长越好，3 秒已是多数业务可接受的临界值；如果调到 5 秒仍频繁触发，大概率是事务粒度或数据访问模式需要重构。
