适配指定聚合管道的MongoDB集合最优索引配置问题

先明确聚合管道各阶段的索引匹配要求 #

当前聚合是按顺序执行的，每个阶段对索引的要求非常明确：

• 第一阶段$match固定过滤country: "US"，需要快速把非目标国家的文档排除掉，避免全集合扫描
• 第二阶段$sort要按createdAt倒序排列所有匹配到的文档，最理想的情况是从索引扫描阶段就拿到天然有序的结果，完全跳过内存排序——毕竟内存排序占用超过100M上限时，聚合会直接执行失败
• 第三阶段$group以id为分组键，取每个分组里排序后第一个文档的totalPrice，如果这两个字段能直接从索引里拿到，就不需要回表读原始文档，能大幅降低IO开销

现有索引的核心问题 #

目前配置的三个索引，没有一个能覆盖全流程的优化需求：

• 单独的{country: 1}索引：只能帮第一阶段过滤出US的文档，过滤完的文档是完全无序的，后续排序必须全量在内存里执行，没有额外收益
• 单独的{createdAt: 1}索引：最左字段是创建时间，根本没法匹配第一阶段的国家过滤条件，对当前聚合来说几乎没用
• 现有的{country: 1, id: 1, createdAt: 1}复合索引：虽然最左的国家字段能命中过滤条件，但索引内部的排序逻辑是「同国家下先按id排序，再按创建时间排序」，根本没法直接提供按createdAt全局排序的结果，排序阶段还是要走内存，执行效率很差

最优索引配置 #

直接建如下复合索引即可匹配全流程优化：
schema.index({ country: 1, createdAt: -1, id: 1, totalPrice: 1 })

为什么这个索引能最优匹配 #

• 最左的country:1直接命中$match的等值过滤，扫描范围从全集合缩小到所有US的文档
• 紧接着的createdAt: -1和聚合里的$sort字段、排序方向完全对齐，索引扫描出来的文档天然就是按创建时间倒序的，根本不需要额外执行排序操作
• 最后补上的id（分组键）、totalPrice（$first取值字段）让整个聚合过程完全被索引覆盖，不需要回表查询原始文档，IO开销降到最低

冗余索引处理建议 #

如果业务没有其他独立查询场景依赖这三个老索引：

• 单独按国家字段查询
• 单独按创建时间范围查询
• 按国家+id的组合维度查询
  那这三个老索引都可以删掉，减少集合写入时的索引维护开销。

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