能，但仅缓解客户端连接与路由分发并发瓶颈；需cpu>90%、连接数超6000或响应失败才有效，误加反致延迟，须先定位真实瓶颈。
临时加 mongos 节点真能缓解双十一流量？
能，但只在特定瓶颈下有效——它不提升单请求性能，也不加速数据读写，只解决客户端连接和路由分发的并发瓶颈。如果你的 mongos 进程 CPU 持续 >90%、连接数打满（netstat -an | grep :27017 | wc -l 超过 6000）、或出现大量 Failed to receive response from mongos，加 mongos 才有意义。
常见误判是：订单查询变慢 → 盲目加 mongos → 结果延迟照旧。实际可能是分片键设计不合理导致全分片广播查询，或者某个 shard 的磁盘 IO 已饱和。先用 db.currentOp({secs_running: {$gt: 5}}) 和 mongostat --host <mongos-host>:27017</mongos-host> 确认瓶颈在哪儿。
如何安全、快速添加 mongos 节点（不重启服务）
mongos 是无状态进程，添加即生效，但必须严格对齐配置：
- 确保新
mongos使用与原有节点**完全一致的--configdb参数**，例如：mongos --configdb configReplSet/config1:27019,config2:27019,config3:27019；配错一个 host 或端口，它就无法加载路由表，所有请求直接失败 - 不要手动修改
mongos的本地缓存——它从 config server 自动拉取元数据，首次启动后约 10 秒内完成同步；可通过sh.status()在任一mongos上验证分片路由是否一致 - 应用层需支持多
mongos地址：驱动连接字符串里填多个mongos地址（如mongodb://mongos1:27017,mongos2:27017,mongos3:27017/），并启用loadBalanced=true（MongoDB Driver 4.0+）或设置maxPoolSize防止单节点连接堆积
为什么加完 mongos 后部分查询反而更慢？
典型原因是客户端未正确轮询，或 mongos 之间元数据不同步：
- 旧版驱动（如 Java Driver 3.x）默认不自动发现新
mongos，需显式调用MongoClientOptions.builder().requiredReplicaSetName(...)并重连 - 如果 config server 副本集有延迟（
rs.printSecondaryReplicationInfo()显示 lag > 1s），新mongos可能加载到过期的 chunk 分布信息，导致请求被错误转发到空分片，触发跨分片重试，延迟翻倍 - 某些聚合操作（如含
$lookup跨库关联）在多mongos环境下可能被不同节点拆解成不一致的执行计划，建议大促前禁用非必要聚合，改用应用层 join
双十一流量过后要不要删 mongos？
可以删，但别直接 kill 进程——要先让流量自然切走：
- 从负载均衡器（如 Nginx、SLB）中摘除该
mongos的健康检查端口（默认不暴露，需在启动时加--httpinterface --rest开启/dbstats接口） - 观察连接数下降至阈值（如
netstat -an | grep :27017 | wc -l - 删完不用任何集群操作，config server 不记录
mongos列表，它只是个“临时工”
真正容易被忽略的是：mongos 本身不持久化状态，但它的日志会暴露出真实瓶颈——比如高频出现 could not find shard key in document，说明业务代码正往未分片集合写数据，这种问题加一百个 mongos 也救不了。
