TypeScript API用Promise.allSettled并行查MongoDB同连接性能反而更差？

首先从你的运行数据就能排除“查询被串行执行”的猜测：如果是完全串行，总耗时应该是三个单查询的耗时之和（3369ms + 3721ms + 3799ms ≈ 10.9s），但你的并行总耗时只有3800ms，说明三个查询的执行流程已经在时间上互相重叠了，并没有被Node.js或者MongoDB驱动强行串行。
你觉得并行没有收益，是三个实际问题叠加导致的：

• 单查询的资源抢占导致性能下降：同一个sid的查询单独跑只要1872ms，并行时要花3369ms，本质是三个查询同时抢占MongoDB的CPU、磁盘IO、连接带宽资源，单查询的执行效率被拖慢，最终总耗时接近最慢的单查询耗时，自然看不出并行优势。
• 连接池排队开销：Node.js MongoDB驱动默认连接池的最大连接数是5，每个连接同一时间只能处理1个数据库请求。你的每个查询内部包含2次独立的数据库往返（先查Content集合、再查Source集合），3个并行分支总共会发起6次数据库请求，这些请求会在连接池队列里排队，进一步增加额外延迟。
• 冗余的重复查询：每个并行分支都会独立发起一次Source集合的查询，就算不同分支拿到的Content有重叠的sourceId，也会重复请求Source集合，浪费连接资源。

1. 匹配调整连接池大小 #

在初始化MongoDB客户端时，把连接池上限调整到大于你最大并行查询数*2的水平，避免数据库请求在连接队列里无意义排队：

// 初始化Mongo客户端的配置示例
const client = new MongoClient(mongoUri, {
  maxPoolSize: 12, // 预留足够的连接给Content、Source查询
  minPoolSize: 3,
});

只要连接数足够，不同的数据库请求就可以被分配到不同的服务端连接上，由MongoDB服务端并行处理。

2. 优先用单查询替代多分支并行 #

你现在的三个查询，过滤条件除了skillId不同之外，其他条件完全一致，完全没必要拆成三个并行请求：

• 把所有需要查询的skillId放到一次$in查询里拉取所有匹配的Content，再在内存里按skillId做分组
• 把所有需要的sourceId去重后，只发起一次Source集合的查询
  这种优化只需要2次数据库往返，比原来3个并行分支总共6次往返的开销低60%以上，性能远好于靠Promise.allSettled堆并行的方式。
  优化后的核心代码逻辑：

const allSkillIds = chosenSkillsArr.map(skill => skill.sid!);
// 一次查询拉取所有匹配的Content
const allContents = await ContentM.find({
  $and: [
    { "skills.skillId": { $in: allSkillIds } },
    { recordStatus: true },
    { curatorId: 0 },
    body.isVideoIncluded ? {} : { type: contentTypeNumber.read },
    { _id: { $nin: contentIds } },
  ]
}).exec();
// 统一收集去重后的sourceId，一次查完所有来源
const sourceIdSet = new Set(allContents.map(c => c.sourceId).filter(Boolean));
const allSources = await new SourceRepo().getByIds(Array.from(sourceIdSet));
// 内存内按skillId分组，和原逻辑返回格式完全一致
const resultMap = allContents.reduce((acc, content) => {
  const contentJson = content.toJSON() as IContentWithSource;
  contentJson.source = allSources.find(s => s._id === content.sourceId);
  content.skills.forEach(skill => {
    if (allSkillIds.includes(skill.skillId)) {
      acc[skill.skillId] = acc[skill.skillId] || [];
      acc[skill.skillId].push(contentJson);
    }
  });
  return acc;
}, {});

3. 给单查询加索引拉低单次耗时 #

如果确实需要按不同skill拆分独立查询（比如每个skill需要加差异化的过滤逻辑），必须给查询条件建联合覆盖索引，把单查询的耗时从秒级降到几十毫秒级别。这种短耗时的请求并行时，才会因为IO等待的重叠拿到明确的并行收益——如果单查询本身就要花近2秒的CPU计算时间，就算并行执行，也会因为抢占CPU资源让总耗时被最慢的请求拖满，没有收益。

• 不是写了Promise.allSettled就一定能拿到并行收益：当数据库请求数超过连接池上限时，排队的请求和串行执行没有本质区别。
• 严格来说，单个MongoDB TCP连接是无法实现请求并行处理的：MongoDB的二进制协议要求连接上同一时间只能有一个在途的请求，你期待的“同一连接下的并行”本质是应用层的异步并发，底层还是靠连接池开多个独立TCP连接，由MongoDB服务端并行处理这些请求。
• 如果单查询本身是秒级的高CPU消耗操作，并行几乎不会带来收益：这类操作会快速占满服务端的CPU资源，并行执行时只会让所有查询的执行时间被拉得更长，不会比单查询的耗时更快。

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