生产环境必须显式配置maxpoolsize和minpoolsize，推荐按真实负载设置（如qps 200时maxpoolsize设50–80，minpoolsize为10%–20%），并同步配置maxidletimems=60000和maxwaittimems=2000，否则易引发连接耗尽、超时或僵尸连接；多mongos需客户端支持负载均衡而非仅uri列表；分片集群下连接池效能受分片键设计与查询模式直接影响。
连接字符串里必须显式配 maxPoolSize 和 minPoolSize
默认连接池大小是 100，但很多业务实际并发远低于这个值，盲目用默认值反而会拖慢启动、增加内存占用、甚至触发 mongos 的连接拒绝。生产环境建议按真实负载设：比如 QPS 稳定在 200 左右，maxPoolSize 设为 50–80 就够用；minPoolSize 则建议设为 maxPoolSize 的 10%–20%，避免冷启时频繁建连。
常见错误现象：mongos 日志里反复出现 connection refused 或客户端报 Timeout waiting for connection，往往不是网络问题，而是连接池耗尽后新请求排队超时。
- Node.js 驱动（v4.0+）中，这些参数只能通过连接字符串传，不能靠驱动自动推断
- Spring Boot 中若用
spring.data.mongodb.uri，必须把maxPoolSize写进 URI，例如：mongodb://mongos1:20000,mongos2:20000/testdb?maxPoolSize=60&minPoolSize=6 - 不要依赖配置文件或环境变量覆盖——MongoDB 驱动不读取那些地方的连接池参数
mongos 节点数和连接池大小要匹配
每个客户端连接只连一个 mongos 实例，不会自动在多个 mongos 间分摊。如果你部署了 3 个 mongos，但客户端只连其中 1 个，那另外两个的连接池再大也没用；反过来，如果客户端轮询连全部 3 个，那单个 maxPoolSize=60，总连接上限就是 180。
使用场景：高吞吐写入服务建议让客户端 DNS 轮询或用负载均衡器（如 Nginx）把请求打散到所有 mongos；低频读服务可固定连一个，节省资源。
- 连接字符串中列出多个
mongos地址（如mongodb://mongos1,mongos2,mongos3/db）≠ 自动负载均衡，仅用于故障转移 - 真正实现连接分散，得靠客户端 SDK 支持（如 Node.js 驱动默认支持多地址发现，但需确认
directConnection=false） - Spring Boot 默认不启用多
mongos负载分发，除非你手动配置com.mongodb.ConnectionString并传入多个 host
别忽略 maxIdleTimeMS 和 maxWaitTimeMS
maxIdleTimeMS 控制空闲连接多久被回收，默认 0（永不回收），长期运行的服务容易积累大量僵尸连接；maxWaitTimeMS 是获取连接的最长等待时间，默认无限等待，一旦连接池满，请求就卡死在这里。
容易踩的坑：本地开发时设了 maxPoolSize=10，但没设 maxWaitTimeMS，结果某次慢查询占着连接不放，后续所有请求全 hang 住，排查时才发现是连接池阻塞而非数据库慢。
- 推荐值：
maxIdleTimeMS=60000（1 分钟），maxWaitTimeMS=2000（2 秒） - 这两个参数必须和
maxPoolSize同时出现在连接字符串里，否则无效 - Java 驱动对
maxWaitTimeMS敏感，Node.js 驱动则更依赖waitQueueTimeoutMS（语义等价，但名字不同）
分片集群下连接池行为和单机/副本集有本质区别
mongos 是无状态代理，它本身不存数据，但所有查询路由、合并、聚合都发生在它这一层。这意味着连接池压力不仅来自业务 QPS，还来自跨分片操作的内部转发次数。一次不含分片键的 find 可能触发 3 次后端连接（每个 shard 一次），而带分片键的查询只走 1 次。
性能影响：如果业务大量执行广播类查询（如未带分片键的 count、aggregate），即使 maxPoolSize 设得合理，mongos 的 CPU 和连接数仍可能飙升——这不是连接池配少了，而是查询模式不合理。
- 检查
mongos的currentOp，重点关注secs_running > 5且from字段为空的慢操作，大概率是广播查询 - 连接池调优前，先用
sh.status()看 chunk 分布是否倾斜，再确认分片键是否被高频查询覆盖 - 连接池数字再大，也救不了设计不当的分片键——哈希分片下范围查询必然广播，这时候该改查询逻辑，而不是加连接数
