事务卡住连接池的根源是连接未释放：开启事务后连接被会话独占，直至提交或显式终止；若阻塞或遗漏session.endSession()，连接永不归还，导致后续请求超时失败。
事务会卡住连接池，不是因为事务本身慢，而是连接没释放
开启事务后，MongoClient 从连接池取出的连接会一直被该会话（Session）独占，直到事务提交或显式终止。如果事务中执行了阻塞操作（如网络延迟、长查询、未加索引的 find）、或应用逻辑忘记调用 session.endSession()，这个连接就永远不会归还池中——后续请求只能排队等，最终触发 Timeout waiting for a pooled item 或 waitQueueTimeoutMS 超时失败。
- Java 驱动里，
ClientSession不是 AutoCloseable，默认不自动回收连接；必须try/finally包裹session.endSession() - Node.js 中，
withTransaction()会自动结束 session，但若手动调用startTransaction()+commitTransaction()，就必须自己确保endSession()被调用 - Python PyMongo 的
with client.start_session() as session:是安全的，但若跳出 with 块（比如 raise 异常未被捕获），仍可能跳过 cleanup
maxPoolSize 不是越大越好，要匹配事务平均生命周期
盲目把 maxPoolSize 从 100 拉到 500，只会让 mongos 或后端 mongod 更快被打满，尤其在分片集群下，每个事务可能跨多个 shard，导致连接乘数效应翻倍。真正有效的做法是：先估算单个事务平均耗时（比如 800ms），再结合 QPS 算出「同时活跃事务数」，然后设 maxPoolSize ≈ 并发事务数 × 1.5（留缓冲）。
- 例如：峰值 QPS=200，事务平均耗时 600ms → 同时活跃约 120 个事务 →
maxPoolSize设为 180 较合理 - 若事务中含
$lookup或聚合阶段，实际耗时可能翻倍，需按监控数据（如db.currentOp({secs_running: {$gt: 1}})）重新校准 -
minPoolSize建议设为maxPoolSize的 10%～20%，避免冷启动时大量建连冲击 mongos
waitQueueTimeoutMS 必须设，且不能只依赖它兜底
waitQueueTimeoutMS 控制新请求在连接池取不到连接时最多等多久。默认值往往为 0（无限等待）或 120000（2 分钟），这在事务卡死场景下等于“坐等崩溃”。应设为略大于 P99 事务耗时（如 3000～5000ms），让失败快速暴露，而不是堆积请求。
- 设太短（如 500ms）：正常波动也会频繁报错，掩盖真实瓶颈
- 设太长（如 30000ms）：请求积压导致线程/内存暴涨，下游服务雪崩
- 配合日志埋点：在
waitQueueTimeoutMS触发时记录session.id和当前堆栈，方便定位哪类事务拖慢了池子
最容易被忽略的：事务内嵌套操作的连接复用陷阱
一个常见误区是认为“事务里调用普通 collection.find() 会自动复用当前连接”——其实不会。驱动会在事务上下文中强制使用该 session 绑定的连接，但如果事务里又开了另一个独立 client.db().collection().find()（没传 session），就会额外从池里再拿一个连接，造成隐式双连接占用。
- Java：所有
collection.find()必须传入session，否则脱离事务上下文 - Node.js：用
collection.find({}, { session })，别漏掉{ session }选项 - Python：所有操作必须在
session.start_transaction()后、session.end_session()前，且显式传session=session - 特别注意：GridFS 操作（如
bucket.uploadFromStream()）不支持事务，混用会导致连接泄漏+事务失败
currentOp 里带 "inTxn": true 且 "secs_running" 持续增长的会话，再反查对应业务代码是否漏了 endSession 或异常路径未覆盖。 
