使用Mongoose、Express的Node.js应用MongoDB查询异常缓慢问题

• 固定11点触发慢查询的共性原因：该现象和集合大小无关（用户提到集合仅1097条，本地环境复现34秒延迟即可排除托管网络问题），核心是固定时段的系统/应用层资源争抢：
  • 本地系统层面的定时IO抢占：绝大多数Windows/macOS的杀毒软件、系统备份脚本会在每日固定时段（多为白天工作时间10-12点）对磁盘进行全盘扫描，MongoDB的数据存储文件一旦被扫描锁定，所有数据库读写操作的IO延迟会飙升数倍，直接拖慢所有数据库请求。
  • Mongoose默认行为触发的索引扫描：Mongoose默认开启autoIndex配置，会在应用运行过程中定时比对Schema定义和数据库实际的索引结构，一旦检测到Schema修改就会触发全集合的索引重建，该操作会对集合加读锁，哪怕只有千余条文档也会导致查询排队数秒到数十秒。
  • 应用内的定时任务抢占：如果应用本身挂载了cron定时任务（比如每日的日志统计、数据同步、清理任务），固定在11点触发，这类任务通常会发起大范围的数据库查询，占满仅个位数大小的Mongoose默认连接池，其他所有业务请求都会在连接队列里等待，表现为全接口变慢。
• 全应用接口普遍偏慢的共性原因：
  • Mongoose连接池默认配置过小：原生默认连接池大小仅为5，只要有1-2个慢查询占住连接不释放，后续所有请求都会进入排队状态，哪怕是查询单条文档的请求也要等几十秒才能拿到连接。
  • 全量返回字段导致的序列化阻塞：当前代码中.select()未指定任何字段，会拉取Case集合下所有文档的全部字段，如果文档中存储了长文本、附件路径、base64资源类的大字段，1097条文档的全量数据序列化会直接占用Node.js单线程的事件循环，阻塞期间所有其他请求都无法被处理。
  • Populate操作的连接排队：populate操作本质是对关联的User集合发起二次查询，如果此时连接池被慢任务占满，哪怕关联查询的逻辑本身很简单，也会因为拿不到连接卡很久。

• 解决固定时段的慢查询问题
  • 关闭Mongoose自动索引构建：在数据库初始化连接时增加配置autoIndex: false，日常需要调整索引时手动执行创建命令即可，避免定时触发的索引扫描锁表。
  • 排查本地定时抢占源：检查系统杀毒软件的定时扫描计划、本地MongoDB的定时备份脚本、应用内的cron任务执行时间，将MongoDB的存储目录加入杀毒软件的扫描白名单，将重资源任务的执行时间调整到非业务时段。
  • 开启MongoDB慢查询日志，将慢查询阈值设为100ms，在11点慢触发时直接定位卡顿的具体操作，排查是否存在全表扫描、锁等待问题。
• 调整数据库连接配置
  • 放大Mongoose连接池配置：将默认连接池大小从5调整到10-20（根据应用并发规模，小型应用10个连接完全足够），连接参数中增加maxPoolSize: 10，同时开启僵死连接检测，避免无效连接长期占用池资源。
  • 排查未回收的数据库句柄：检查所有查询是否正确捕获异常、正确释放连接，避免因未处理的错误导致连接泄露，长期运行后占满整个连接池。
• 针对当前GET /cases接口做针对性优化
  • 去掉无意义的全量字段查询：将空的.select()替换为接口实际需要返回的字段列表，比如.select('title created_by create_time description')，过滤掉不需要的大字段，减少查询返回的数据量和序列化耗时。
  • 在Case集合的created_by字段上建立普通索引，优化populate操作的查询效率。
  • 即使集合当前规模较小，也要限制单接口的最大返回量，避免未来文档量增长后全量拉取把Node内存打满，导致事件循环阻塞。
• 全链路慢请求排查
  • 在Express层增加请求耗时统计中间件，记录每个请求从接入到返回的全链路耗时，明确卡顿是出现在数据库等待、业务逻辑处理还是序列化环节。
  • 排查全局代码中的同步阻塞操作：比如同步文件读取、大对象的同步循环处理逻辑，这类操作会直接卡住Node的单线程事件循环，导致所有请求无意义排队。

内容的提问来源于stack exchange，提问作者devener101