transactionlifetimelimitseconds仅兜底事务总时长，默认60秒，不干预prepare阶段卡顿、网络分区或commit响应丢失；其生效需协调分片主动abort，且受最短分片配置限制。
超时不是因为 TransactionLifetimeLimitSeconds 没调，而是它根本管不住你遇到的“卡住”场景。 这个参数只对「事务从开始到被服务端自动 abort」起全局兜底作用（默认 60 秒），但跨分片事务真正的瓶颈在两阶段提交（2PC）的 prepare 阶段——某个分片迟迟不响应，整个事务就挂在那里，TransactionLifetimeLimitSeconds 不会提前触发，直到最后才 abort，此时客户端早已超时或断开。
为什么改了 TransactionLifetimeLimitSeconds 还是超时？
这个参数是服务端的“保底熔断”，不是实时监控器。它只在事务处于 active 状态且持续时间超过设定值后，由协调分片（coordinator shard）主动发起 abort。但以下情况它完全不干预：
- prepare 阶段中，某分片因锁争用、慢查询、未建索引导致
db.collection.updateOne()卡住 20 秒 —— 此时事务仍算“active”，TransactionLifetimeLimitSeconds不计时中断 - 网络分区导致 mongos 与一个 shard 失联，prepare 请求发不出去，事务状态停滞在 “starting” —— 该状态不计入生命周期计时
- 客户端调用
session.commitTransaction()后，commit 消息发出但未收到响应，服务端其实已 commit 成功，但客户端等不到回包 —— 这属于UnknownTransactionCommitResult，和生命周期无关
TransactionLifetimeLimitSeconds 的真实影响范围
它只约束「事务上下文存在时间」，不约束操作执行耗时。调整它要结合具体部署层级：
- 在 config server 上设置（通过
sh.setBalancerState(false)后修改配置库）会影响整个集群，但需滚动重启所有 mongos 和 shard 才生效 - 在单个 shard 上用
db.adminCommand({setParameter: 1, TransactionLifetimeLimitSeconds: 120})只对该 shard 有效，但跨分片事务仍受最短的那个限制（木桶效应） - 设得过大（如 300 秒）会导致长事务长期占用连接和内存，尤其在高并发下容易拖垮 mongos 连接池
- 设得太小（如 10 秒）会让正常但稍慢的事务被无差别 abort，掩盖真实性能问题
比调参更关键的三件事
真正决定分布式事务是否“准时完成”的，是 prepare 阶段的稳定性，不是生命周期上限：
- 检查每个 shard 的锁等待：连上各 shard 执行
db.currentOp({ "secs_running": { "$gt": 2 }, "waitingForLock": true })，确认有没有阻塞源 - 确保所有参与集合都有合理索引：事务内
updateOne({ status: "pending" })必须命中索引，否则全表扫描直接卡死 prepare - 禁用可能干扰 2PC 的管理操作：比如在事务高峰期执行
sh.splitAt()或sh.moveChunk()，这些会短暂阻塞分片的 prepare 流程
最容易被忽略的是：事务里混了对非分片集合的写操作，或者用了 createCollection —— 这类操作会让事务连启动都失败，报 IllegalOp，但错误日志可能被淹没在 mongos 日志里，看起来就像“莫名超时”。
