mongos通过shardingtaskexecutorpool中的taskexecutor复用底层到shard的连接，实际复用由libmongoc的connectionpool实现；关键参数为shardingtaskexecutorpoolmaxsize、minsize及环境变量mongoc_pool_max_size。
mongos 怎么复用底层到 Shard 的连接
mongos 本身不维护长连接池，它把每个请求转发给 Shard 时，会从 ShardingTaskExecutorPool 中获取一个 TaskExecutor，再由这个执行器管理底层到 Shard 的连接。真正复用连接的是这个线程池背后的 ConnectionPool（基于 libmongoc），不是 mongos 自己“缓存”连接。
所以关键不在 mongos 配置连接数，而在控制 ShardingTaskExecutorPool 的并发度和每个执行器的连接池行为：
-
shardingTaskExecutorPoolMaxSize控制最多启动多少个后台任务线程（默认 128），每个线程持有一个独立的ConnectionPool -
shardingTaskExecutorPoolMinSize控制预热线程数（默认 0），设为非零可避免突发请求时频繁创建线程 - 每个
ConnectionPool默认最大连接数是 100（由 libmongoc 决定），无法通过 mongos 参数直接调大，但可通过环境变量MONGOC_POOL_MAX_SIZE影响（需在 mongos 启动前设置）
为什么改了 shardingTaskExecutorPoolMaxSize 没效果
常见现象：加大 shardingTaskExecutorPoolMaxSize 后，mongos 进程内存上涨、CPU 升高，但到 Shard 的连接数没明显增加，甚至 QPS 反而下降。
这是因为：
- 线程数不是越多越好 —— 每个
TaskExecutor线程都带独立连接池、心跳任务、超时逻辑，资源开销不小 - 实际连接复用率取决于请求模式：短平快查询（如单文档 find）容易被同一线程反复处理，连接复用高；长耗时命令（如聚合 + $lookup 跨分片）会阻塞线程，导致新请求被迫分配到新线程，反而摊薄复用率
- Linux 文件描述符限制（
ulimit -n）可能卡住连接创建，此时增大线程数只会触发更多Failed to create new connection错误
ShardingTaskExecutorPool 相关错误怎么看
典型报错基本都落在日志里，不是 shell 报错，得查 mongos 日志（默认输出到 stdout 或指定 --logpath）：
-
Failed to schedule task on executor: TaskExecutor is shutting down→ mongos 正在关闭，或shardingTaskExecutorPoolMinSize设太高导致线程回收异常 -
Failed to create new connection: Connection refused→ 后端 Shard 不可用，或连接池已满且所有连接都在忙，不是 mongos 配置问题，先查 Shard 健康 -
Exceeded time limit for waiting for a connection from the pool→ 连接池耗尽，常见于突发流量 +shardingTaskExecutorPoolMaxSize过小，或后端 Shard 响应慢拖垮连接周转
线上 mongos 连接池调优的实操建议
别一上来就调参数。先确认瓶颈在哪：
- 用
db.currentOp({secs_running: {$gt: 5}})看 mongos 上有没有卡住的请求；用netstat -anp | grep :27017 | wc -l粗略看 mongos 到各 Shard 的 ESTABLISHED 连接数 - 如果连接数远低于预期（比如只有几十个），大概率是请求量不够或请求太散，调大
shardingTaskExecutorPoolMaxSize没意义 - 如果连接数稳定在 100×N（N 是线程数），且出现大量
Exceeded time limit...，说明连接池满，优先检查 Shard 延迟，其次考虑增大MONGOC_POOL_MAX_SIZE环境变量（例如设为 200），再重启 mongos - 生产环境建议：保持
shardingTaskExecutorPoolMinSize = 16（防冷启抖动），shardingTaskExecutorPoolMaxSize = 64（够用且可控），不盲目堆线程
真正影响复用效率的，从来不是 mongos 的线程数，而是请求分布是否集中、Shard 是否响应及时、网络是否稳定。参数只是兜底，不是银弹。
