Express中setInterval异步回调耗时递增及MongoDB查询优化问题

场景复现 #

我在Express项目中使用setInterval执行异步定时任务，代码如下：

setInterval(async () => {
  const result = await getData(1000 * 60)
  // 向前端通过socket发送结果
  chat.emit('/total/IO/metric/1s', result)
}, 1000)

TcpDataDa.getData的实现逻辑：

async function getData(ms) {
 ...
 const start = new Date()

 const resultsFromTcpData = await TcpDataModel.aggregate([
    {
      $match: {
        timestamp: {$gte: startMS, $lte: startMS + ms},
      },
    },
  ])

 const end = new Date()
 console.log(end - start)
}

该聚合查询会从MongoDB的240万条数据中筛选出12万条，统计的查询耗时（毫秒）如下：

1322
1790
2190
2242
2767
3690
4332
4740
4933
5037
5483
5544
5629
5758
5922
6472
6540
6688
6860
7031
7210
7551

可见耗时持续递增，但将setInterval间隔改为2秒后，耗时保持稳定：

setInterval(async () => {
  const result = await getData(1000 * 60)
}, 2000)

对应的稳定耗时数据：

1220
1134
1131
1143
1132
1134
1160
1115
1121
1147
1102
1100
1137
1108
1140
1107
1106
1126
1096
1123
1101
1130
1084
1094
1096
1168

技术问题与解答 #

1. 为何查询耗时会逐渐递增？是否仅同一定时器的查询才会导致此问题？ #

你的猜测完全正确：当setInterval的1秒间隔小于查询实际耗时（很快突破1秒）时，前一次查询还未结束，新的定时器回调就已触发，导致并发查询堆积。这些堆积的查询会抢占MongoDB连接池资源、Node.js事件循环线程，同时MongoDB处理并发查询本身也会产生额外开销，最终导致每一次查询的耗时逐步攀升。

不止同一定时器，所有运行中的类似异步定时任务都会互相影响——它们共享Node.js的事件循环和MongoDB的连接池。如果其他定时器也在执行耗时操作，会进一步加剧资源竞争，导致整体性能下降。

2. 如何解决该问题？需要每秒更新数据展示实时图表，无法延长间隔时间。 #

核心思路是彻底避免并发查询堆积，同时优化查询效率：

• 用递归setTimeout替代setInterval：确保前一次异步任务完成后再调度下一次，从根源上杜绝堆积：

  async function runTask() {
    try {
      const result = await getData(1000 * 60)
      chat.emit('/total/IO/metric/1s', result)
    } catch (err) {
      console.error('任务执行失败:', err)
    } finally {
      // 无论成功失败，1秒后启动下一次任务
      setTimeout(runTask, 1000)
    }
  }
  // 启动任务
  runTask()
  

• 优化MongoDB查询：
  • 确认timestamp_1索引生效的前提下，创建覆盖索引：如果查询只需要特定字段，创建包含这些字段的复合索引，避免回表查询，进一步降低耗时。
  • 考虑按时间分集合：将数据按小时/天拆分到不同集合，大幅减少单集合的数据量，提升查询速度。
  • 限制返回字段：在aggregate中添加$project阶段，只返回前端需要的字段，减少数据传输和解析的耗时。
• 调整MongoDB连接池大小：在Mongoose连接配置中适当提高poolSize（比如20-50，根据服务器资源调整），避免因连接不足导致查询等待，但注意不要超过MongoDB的最大连接数限制。

3. 该查询耗时是否正常？为何Compass中仅162毫秒，后端却要1秒以上？ #

当前后端1秒以上的耗时明显过高，正常情况下后端查询耗时会比数据库端高，但差距不应如此悬殊，主要原因包括：

• 数据传输与解析：Compass直接连接MongoDB，数据传输路径短；而后端通过Node.js驱动传输12万条数据，需要序列化/反序列化JSON，这会占用大量Node.js线程时间，导致耗时增加。可通过限制返回字段、减少单批次数据量优化。
• 连接池等待：并发查询堆积时，新查询需要等待连接池中的可用连接，这部分等待时间会被计入你的end - start统计中。
• Node.js事件循环阻塞：如果其他异步任务或同步代码占用了事件循环线程，会导致MongoDB驱动的回调无法及时执行，拉长整体耗时。

你可以在getData中单独统计数据库查询的耗时（仅await TcpDataModel.aggregate前后的时间差），与当前总耗时对比，就能明确是数据库查询慢，还是数据传输/解析、事件循环阻塞导致的耗时。

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