MongoDB故障码110是一个让不少运维和开发人员头疼的错误，它一般表现为操作在规定时间内没有得到服务端响应，驱动层抛出网络超时异常。这个故障码本身并不复杂，复杂的是它背后的成因：可能是网络链路不稳定，可能是连接池被打满，也可能是服务端执行某个慢查询把资源耗尽了。要真正解决问题，需要理解MongoDB的超时机制，然后按照客户端、服务端、网络三个层面逐层排查。
一、故障码110的产生原理与超时机制
在MongoDB的驱动体系中，网络超时主要由socketTimeoutMS和serverSelectionTimeoutMS这几个参数控制。当客户端向服务端发送一个请求后，驱动会启动一个计时器，如果在这个时间窗口内没有收到任何响应，连接就会被判定为失效，驱动随即抛出带有错误码110的异常。
需要特别区分的是，socket超时和服务器选择超时是两回事。socket超时指的是单次读写操作在TCP层面的等待上限，而服务器选择超时指的是驱动在副本集拓扑中挑选可用节点的等待上限。很多开发者把两者混为一谈，结果调了半天的参数没调对地方。故障码110通常对应的是前者，也就是某一次具体的读写操作超时了。
还有一个容易被忽略的细节：超时并不一定意味着操作失败了。MongoDB在收到请求后，如果操作本身已经提交，只是响应没能及时传回客户端，客户端虽然报了110，但数据可能已经写入成功。这也是为什么在处理这类异常时，建议通过业务层面的幂等性设计来兜底，而不是简单地重试了事。
二、客户端层面的排查与配置优化
客户端是故障码110最常见的诱因来源。第一步要检查的是连接池配置，默认的maxPoolSize是100，如果应用的并发量远超这个数字，大量请求会在等待可用连接时触发超时。以Node.js驱动为例，可以这样调整：
const { MongoClient } = require('mongodb');
const client = new MongoClient('mongodb://192.168.0.1:27017/mydb', {
maxPoolSize: 200, // 最大连接数，按并发量调整
minPoolSize: 20, // 预热的最小连接数，避免突发流量时建连延迟
socketTimeoutMS: 60000, // socket读写超时，单位毫秒
serverSelectionTimeoutMS: 10000,
connectTimeoutMS: 10000, // 建立TCP连接的超时时间
});
client.connect().then(() => {
console.log('连接成功');
});
第二步要检查是否存在慢操作占用连接过久的情况。一个聚合查询如果执行三十秒，它就会占住一个连接三十秒，高并发下几个这样的慢查询就能把连接池拖垮。可以在应用日志里统计出现110错误时正在执行的语句，看看是否集中在某几类查询上。如果是，优化方向应该是给这些查询建立合适的索引，或者拆分大查询。
第三步是确认驱动版本。旧版本的驱动在处理副本集故障转移时存在已知缺陷，主节点切换期间的请求容易集中报110。升级到与服务器版本匹配的稳定驱动版本，往往能消掉一批不明原因的超时。
三、服务端与网络层面的定位手段
如果客户端配置没有问题，就要把目光转向服务端。MongoDB提供了几个非常好用的诊断工具，第一个是当前操作快照：
// 在mongosh中执行，查看当前正在运行的操作
db.currentOp({
active: true,
secs_running: { $gte: 3 } // 只显示执行超过3秒的操作
});
这个命令能直接暴露出执行时间过长的操作，配合db.killOp()可以紧急止损。长期方案是开启慢查询日志，在配置文件中设置slowms为100毫秒左右，让所有慢操作都记录下来，再通过分析日志找出需要优化的查询模式。
服务端状态方面，重点看这几个指标：connections.current是否逼近connections.available，globalLock.currentQueue中等待的读写请求数量，以及内存是否发生了交换。任何一个指标异常，都会间接表现为客户端的网络超时。可以用下面的命令快速获取：
// 查看服务器状态摘要 db.serverStatus().connections; db.serverStatus().globalLock.currentQueue; db.serverStatus().mem;
网络层面则要借助系统工具。用ping观察延迟和丢包率，用traceroute确认链路路径，如果是跨机房部署，还要考虑中间网络设备的会话超时设置。有一种很典型的情况：防火墙或负载均衡器会把空闲超过一定时间的TCP连接强制断开，但客户端并不知情，下次复用这个连接时就报110。解决办法是在连接字符串里启用心跳保活，例如设置heartbeatFrequencyMS为10000，让驱动定期发送心跳维持连接活性。
四、建立完善的监控与容错机制
单次故障处理好只是治标，要避免故障码110反复出现，还需要体系化的保障。监控方面，建议对以下指标设置告警：连接池使用率超过80%、P99查询延迟超过500毫秒、副本集复制延迟超过10秒。这些指标恶化往往是超时故障的前兆，提前介入能避免事故扩大。
容错方面，应用层要实现合理的重试逻辑。MongoDB 4.2之后的驱动支持可重试写入和可重试读取，开启之后，遇到网络抖动驱动会自动重试一次，大部分瞬时故障用户完全无感知。同时业务代码中要保证写操作的幂等性，这样即使重试也不会产生脏数据。
最后提醒一点，调大超时时间永远只是缓兵之计。如果系统频繁报110，根本原因大概率是慢查询、资源不足或网络架构问题。把超时时间从30秒改到60秒，只是把故障延迟暴露，正确做法是顺着本文的排查思路找到性能瓶颈，从源头解决问题，这样才能让数据库长期稳定运行。
MongoDB网络超时MongoDB故障码110MongoDB连接超时修改时间：2026-09-13 10:32:28