NestJS+MongoDB电商API调用1个与2个服务的性能优化问题

数据库层优化（核心优化点） #

• 调整聚合管道执行顺序，将公共过滤的$match阶段放在管道最前端，提前过滤不符合条件的商品，缩小后续阶段的处理数据量。如果当前是分别调用两次聚合查询返回筛选器和商品列表，改用$facet阶段将两次查询合并为一次数据库请求，减少IO开销。
• 为所有用于过滤、排序、分组的字段创建匹配聚合逻辑的联合索引，使用Mongoose的aggregate().explain()方法查看执行计划，排查全表扫描、内存排序等低效执行逻辑，确保排序、过滤逻辑都能命中索引。如果聚合处理数据量较大，添加allowDiskUse: true配置避免内存溢出。
• 若筛选器取值更新频率较低，不要每次请求都实时聚合统计筛选器取值，单独维护一张筛选器配置表，在商品属性变更、上下架时异步更新该表，接口请求时直接查表返回筛选器，省去实时聚合的开销。

业务逻辑层优化 #

• 无意义拆分服务不会带来性能提升，性能瓶颈核心在数据库IO而非服务实例化环节，优先优化查询逻辑而非业务代码组织结构。
• 提前校验请求参数合法性，拦截参数格式错误、取值不在可选范围的无效请求，避免无意义的数据库查询。限制商品列表单次返回条数，按分页返回每次最多20~50条，降低数据序列化、传输耗时。

缓存层优化 #

• 使用Redis缓存高频查询参数对应的接口返回结果，缓存过期时间可根据商品更新频率设置为5~30分钟，后台商品数据变更时主动清除对应缓存。
• 按多语言、站点等维度做缓存分片，相同维度相同查询参数的请求可直接命中缓存，无需重复查库。

降级与归档优化 #

• 大促高峰期可做降级策略，优先返回商品列表数据，筛选器异步加载或返回预计算的默认取值，保障核心路径可用。
• 将已下架、不会再变更的历史商品归档到单独集合，查询时仅检索在售商品集合，进一步缩小查询数据集。

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