maxpoolsize必须大于事务并发峰值，否则事务请求会因连接不足而超时；建议按峰值事务数×1.3设置，并配合minpoolsize（10%～20% maxpoolsize）和maxidletimems（30秒）保障冷启动稳定性。
maxPoolSize 必须大于事务并发峰值
事务会独占连接直到提交或回滚，不能像普通查询那样快速归还连接池。如果 maxPoolSize 小于实际并发事务数，后续事务请求会卡在等待队列里，触发 waitQueueTimeoutMS 超时并抛出 MongoWaitQueueTimeoutException（Java）或类似驱动级超时错误。
实操建议：
- 先用
db.serverStatus().connections观察生产环境事务高峰期的current连接数，取 95 分位值作为基线 - 设置
maxPoolSize≥ 峰值事务并发 × 1.3（留缓冲），例如观察到峰值 80 个事务连接，至少设为 105 - Node.js 驱动中不要依赖默认值（100），尤其当应用同时跑大量非事务查询 + 事务混合负载时，需单独评估事务连接占比
- 避免把
maxPoolSize设到 500+，除非你已确认服务器内存、文件描述符和 MongoDBmaxConnections都支撑得住
minPoolSize 和 maxIdleTimeMS 要配合事务冷启动场景
事务密集型服务刚启动或低峰后突增流量时，若连接池为空，每个新事务都要新建连接——SSL 握手 + 认证 + 网络延迟叠加，首事务延迟可能飙升到秒级。此时 minPoolSize 和 maxIdleTimeMS 就不是“可选配置”，而是稳定性保障。
实操建议：
-
minPoolSize设为maxPoolSize的 10%～20%，例如maxPoolSize: 120→minPoolSize: 15 -
maxIdleTimeMS设为 30000（30 秒），比常见云防火墙空闲超时（如 AWS NLB 默认 3500 秒）短，但远长于单次事务耗时，防止连接被中间设备静默断开 - 不建议设
maxIdleTimeMS: 0，长期空闲连接可能被 mongos 或 proxy 强制回收，反而引发重连抖动
事务期间连接无法复用，别指望 readPreference 缓解压力
很多人误以为用 readPreference=secondaryPreferred 能把事务里的读操作分流出去——不行。MongoDB 事务必须全程绑定到同一个节点（通常是 primary），所有读写都在该连接上串行执行。事务内的读不会走从节点，readPreference 在事务上下文中被忽略。
这意味着：
- 事务吞吐量完全受限于单节点处理能力，连接池只是“通道”，不是“分流器”
- 如果你发现事务延迟高，优先看 primary 节点 CPU、锁争用、WiredTiger cache 命中率，而不是调大连接池
- 想扩容事务能力，得横向扩展（sharding）或拆分事务粒度，不是堆
maxPoolSize
Laravel / ET / NestJS 等框架里容易漏掉的坑
框架封装常隐藏底层驱动细节，导致连接池配置失效。典型表现：代码里写了 maxPoolSize: 200，但 db.serverStatus().connections.current 死活不上 50。
常见原因：
- Laravel MongoDB 包（jenssegers/laravel-mongodb）默认不透传
options到原生驱动，必须显式在config/database.php的options数组里写全，且确保版本 ≥ 3.10 - ET 框架中若使用连接字符串而非 MongoClient 实例配置，
maxPoolSize参数需拼在 URI 后：mongodb://host:27017/db?maxPoolSize=200 - NestJS 的
@nestjs/mongoosev9+ 支持connectionOptions，但旧版只认useNewUrlParser等字段，maxPoolSize写了也无效 - 所有框架都需确认：是否每个
MongoClient实例对应一个独立连接池？多模块重复 new Client 会导致多个池，总连接数 = 实例数 ×maxPoolSize
current 和 available 的差值比调参更重要。
