maxtimems设太短会导致服务端在指定时间一到即中止事务并清理上下文，使后续committransaction()必然失败，报transaction not found或maxtimemsexpired；该值从session.starttransaction()开始计时，覆盖整个事务生命周期，默认60秒常不足，实操建议基于实测耗时乘1.5设定，且需同步调优heartbeatfrequencyms、transactionlifetimelimitseconds及sockettimeoutms等参数。
maxTimeMS设太短，事务还没跑完就被服务端中止
事务超时不是客户端“等不及”，而是服务端在maxTimeMS时间一到就主动清理上下文，后续commitTransaction()必然失败，报Transaction not found或MaxTimeMSExpired。这个值从session.startTransaction()开始计时，覆盖整个事务生命周期（含查询、更新、网络延迟），默认60秒往往不够用。
实操建议：
- 先用
db.currentOp({ "secs_running": { "$gt": 5 } })查真实耗时，重点关注secs_running和active字段 - 在测试环境跑通一次完整业务流，记录从
startTransaction()到commitTransaction()的总耗时，再乘1.5作为maxTimeMS值（比如实测8秒 → 设12000） - Node.js驱动必须在
session.startTransaction({ maxTimeMS: 12000 })里传参，不能事后修改；PyMongo同理，且max_commit_time_ms只影响commit_transaction()阶段，不延长事务整体存活时间 - 避免全局设成300000（5分钟）：高并发下会拖垮连接池，尤其跨分片事务中，一个慢分片就能卡住全部
事务里混了慢操作，悄悄吃掉超时预算
有些操作表面看不重，实际开销极大，且容易被忽略。比如countDocuments()在无索引字段上全表扫描，比find().toArray()更隐蔽；$lookup关联非事务集合虽不报错，但远程查询延迟直接计入maxTimeMS；upsert: true若匹配条件无唯一索引，会先查后插，两次I/O叠加耗时。
常见诱因：
- 未加索引的
find或update在大集合上执行 - 事务内发起HTTP调用或文件IO，网络抖动直接命中超时
- 批量写入数据量远超预估，WiredTiger写放大导致commit变慢
- 跨分片事务中，任意一个分片响应慢，整个事务卡住
网络延迟高，心跳和事务超时没对齐
跨AZ或跨Region部署时，RTT达50–100ms，但默认heartbeatFrequencyMS=10000（10秒）会让驱动误判节点失联；同时服务端transactionLifetimeLimitSeconds仍为60秒，而客户端socket可能已被SLB或Nginx断开，报context deadline exceeded或Transaction is not in progress。
必须同步调整：
-
heartbeatFrequencyMS设为2000（2秒），electionTimeoutMillis设为10000（10秒），保持1:5比例 -
transactionLifetimeLimitSeconds调至180（3分钟），需在mongod启动参数或副本集配置中修改 - 客户端
socketTimeoutMS不能设为0（无限），建议略大于P99事务耗时（如5000）
连接没释放，事务卡死导致后续全阻塞
事务开启后，连接被会话独占，直到commitTransaction()或abortTransaction()完成。如果逻辑里漏掉session.endSession()，或异常跳出with块（PyMongo）、没包try/finally（Java），连接就永远滞留，最终触发Timeout waiting for a pooled item。
关键点：
- PyMongo用
with client.start_session() as session:是安全的，但异常未捕获时仍可能跳过cleanup - Node.js手动调用
startTransaction()时，必须确保session.endSession()被执行，withTransaction()会自动处理 -
maxPoolSize不能盲目调大——要按“峰值QPS × 平均事务耗时”估算并发事务数，再加50%缓冲；否则分片集群下连接数会乘数级膨胀
maxTimeMS和transactionLifetimeLimitSeconds作用范围不同，前者由客户端控制，后者由服务端强制；而heartbeatFrequencyMS看似无关，却在高延迟下成为压垮事务的最后一根稻草。
