MongoDB驱动程序维护着一个客户端连接池，当所有连接都被占满且等待队列也排满时，新的获取连接请求就会失败，驱动会抛出带有1260错误码的异常。这个错误并不一定表示MongoDB服务器宕机，更多时候是客户端连接池的配置或使用方式出了问题。比如一个批量任务瞬间发起上千个查询，而maxPoolSize只有50，连接池很快耗尽；又或者某个业务在获取连接后没有正确归还，导致可用连接越来越少。

要理解1260错误码，需要先弄清驱动获取连接的过程。MongoDB官方驱动（如PyMongo、Java驱动、Node.js驱动）内部都实现了连接池。当一个请求需要执行数据库操作时，驱动会先尝试从连接池中取出一个空闲连接。如果当前活跃连接数小于maxPoolSize，驱动会直接创建新连接并返回；如果活跃连接数已经达到上限，请求会进入等待队列。等待队列也有长度和超时限制，由waitQueueTimeoutMS等参数控制。当等待时间超过阈值，驱动就会抛错，错误码在不同语言驱动中可能映射为1260。

需要注意的是，1260错误码通常来自客户端驱动层，而不是MongoDB服务器本身。服务器端的错误码一般以类似8000、11000等数字出现，而1260代表连接池资源耗尽，意味着问题出在客户端访问方式或池参数配置上。如果看到数据库服务运行正常但业务频繁报1260，就应该把排查重点放在客户端。

一、连接池耗尽的四个主要原因

连接池耗尽并不是单一原因造成的，常见情况可以归纳为以下四类。

• 突发流量超过池容量：定时任务、数据迁移、缓存击穿导致的集中回源查询，可能在几秒内将连接池打满。比如maxPoolSize=100，但某个接口突然并发1000次请求，等待队列很快溢出。
• 慢查询占用连接时间过长：如果一个查询需要5秒甚至更久才能返回，连接就会被占用5秒。同样的请求速率下，连接池很容易被慢查询拖垮。未使用索引、大量数据排序、集合扫描都是常见原因。
• 连接泄漏：代码中获取了数据库连接但没有在finally块中关闭游标或客户端，连接无法及时归还，池中的可用连接数不断减少，最终耗尽。Java开发中忘记调用close()是最典型的场景。
• 池参数设置不合理：waitQueueTimeoutMS设置过短会让正常排队请求提前失败；minPoolSize过小会导致流量波动时频繁创建连接；没有设置maxIdleTimeMS可能让空闲连接长时间占用资源。

在实际生产环境里，往往是几个因素叠加导致问题爆发。例如连接池本来就偏小，突然上线的报表任务又产生了大量慢查询，同时部分历史代码存在连接未关闭的情况，最终表现为1260错误大面积出现。

要判断具体是哪种原因，不能只盯着错误日志，还需要结合连接池的运行时指标。下一节会介绍如何获取这些信息。

二、如何快速定位连接池耗尽问题

定位连接池问题的第一步是确认是否真的达到了池上限。很多驱动支持注册连接池事件监听器，可以把连接创建、关闭、借出、归还的动作打印出来。以PyMongo为例，可以通过monitoring模块注册监听器，实时观察连接池的活跃数量变化。

from pymongo import monitoring
import logging
class PoolListener(monitoring.ConnectionPoolListener):
    def connection_created(self, event):
        logging.info("连接已创建: %s", event.address)
    def connection_closed(self, event):
        logging.info("连接已关闭: %s", event.address)
    def connection_checked_out(self, event):
        logging.info("连接被借出: %s", event.address)
    def connection_checked_in(self, event):
        logging.info("连接已归还: %s", event.address)
monitoring.register(PoolListener())

上述代码中的connection_checked_out和connection_checked_in事件分别对应连接借出和归还。如果日志显示借出数量持续增长而归还数量没有跟上，基本可以判断存在连接泄漏。如果借出和归还数量大致平衡，但等待队列经常有积压，则可能是慢查询或突发流量导致。

除了日志，还可以查看MongoDB服务器端的serverStatus输出中的连接统计字段，例如current、available、active。在服务器上执行db.serverStatus().connections可以获取这些指标。当current接近操作系统允许的最大连接数，或者客户端连接池的active长时间保持在高位，说明连接资源已经非常紧张。把客户端监控和服务器监控结合起来，能够更快缩小问题范围。

三、修复连接池耗尽的配置与代码调整

确认原因之后，可以从配置和代码两个层面同时入手。先看连接池参数。如果确实因为并发峰值超过池容量导致1260错误，最直接的办法是适当调高maxPoolSize。但需要注意，maxPoolSize不是越大越好，每个连接都会占用MongoDB服务器和客户端的内存、文件描述符。一般来说，单台应用服务器的连接池大小可以在100到300之间，具体数值要根据压测结果和服务器配置确定。如果是突发流量，单纯调大池容量只能暂时缓解，还需要在业务侧做限流或异步化处理。

对于Java驱动，可以使用连接字符串配置关键参数：

import com.mongodb.client.MongoClients;
import com.mongodb.client.MongoClient;
import com.mongodb.ConnectionString;
ConnectionString connString = new ConnectionString(
    "mongodb://user:pass@localhost:27017/?maxPoolSize=200&minPoolSize=20&waitQueueTimeoutMS=5000&maxIdleTimeMS=60000"
);
MongoClient mongoClient = MongoClients.create(connString);

这里把maxPoolSize提升到200，同时设置了minPoolSize=20用于预热连接，避免冷启动时大量连接建立带来的延迟。waitQueueTimeoutMS=5000表示请求最多等待5秒，这个值不宜过大也不宜过小。如果设成0或负数，有些驱动会认为无限等待，反而可能把业务线程全部拖住。

除了调参，代码中还要保证连接正确归还。以Java为例，使用try-with-resources可以自动关闭客户端和游标：

try (MongoCursor<Document> cursor = collection.find(filter).iterator()) {
    while (cursor.hasNext()) {
        Document doc = cursor.next();
        System.out.println(doc.toJson());
    }
}

上面这段代码借助try-with-resources语法，在代码块结束时自动调用close()，即使中途抛出异常也能保证连接归还。如果项目使用的是旧版本Java或无法使用该语法，则需要在finally块中显式关闭游标和客户端。

如果存在慢查询，则需要通过explain()分析执行计划，补充合适的索引。慢查询会让连接长时间无法释放，索引优化有时比单纯调大池参数更有效。可以使用db.currentOp()找出执行时间超过阈值的操作，再针对性的优化。

四、建立长期预防机制

解决眼前的1260错误只是第一步，更重要的是建立一套连接池监控和预警体系。可以在应用层把连接池的关键指标暴露给Prometheus或类似监控系统，例如当前活跃连接数、空闲连接数、等待队列长度、连接获取耗时。当等待队列长度持续大于0或连接获取耗时超过设定阈值时发出告警，这样能在连接池彻底耗尽之前提前介入。

另外，定期审查代码中是否存在连接泄漏风险也非常重要。静态检查工具可以帮助发现未关闭的游标和客户端对象。对于核心业务，可以编写集成测试，模拟高并发场景并监控连接池使用率。如果测试后连接数不能回落到初始值，就说明存在泄漏。

最后，把慢查询日志和连接池指标放在同一个看板中分析，能更清楚地看到两者的关联。比如慢查询数量上升后，连接池活跃连接数同步上升，等待队列开始积压。此时优化的优先级应该是索引和查询逻辑，而不是盲目增加连接数。长期来看，合理的池配置、规范的代码资源管理、完善的监控告警三者配合，才能从根本上避免1260连接池耗尽错误再次出现。