MongoDB聚合查询$sort阶段无法使用索引的问题求助

我来帮你分析下这个问题：你的distinct查询能快速命中索引是因为MongoDB对distinct有专门的DISTINCT_SCAN优化，可以直接从索引里提取唯一值，完全不用扫描文档；但聚合管道的默认行为会先做全表扫描（COLLSCAN），再排序，这就是为什么耗时差这么多。下面是具体的解决办法：

核心原因 #

你的聚合管道里的$sort没用到索引，主要是因为查询优化器没有选择走索引路径——哪怕你建了索引，当管道开头没有过滤条件（$match）时，优化器可能默认选择全表扫描，尤其是面对多键索引（你的events是数组，所以events.hi2.ClientId是多键索引）的时候。

解决方案 #

1. 强制指定索引（最直接的办法） #

在聚合的$cursor阶段加上hint，强制查询优化器使用你建好的ClientId索引，这样就能避免全表扫描：

db.getCollection('data').aggregate( [
  { $cursor: {
      query: {},
      fields: { "events.hi2.ClientId": 1, "_id": 0 },
      hint: "ClientId" // 可以用索引名，或者索引键模式 { "events.hi2.ClientId": 1 }
    }
  },
  { "$sort": { "events.hi2.ClientId": 1 } },
  { "$group": { "_id": "$events.hi2.ClientId" } }
], { allowDiskUse: true })

这样执行的时候，$cursor会走索引扫描而不是全表扫描，后续的$sort也能直接利用索引的有序性，不需要再做内存/磁盘排序。

2. 利用索引有序性，省略$sort阶段 #

既然索引本身就是按events.hi2.ClientId:1排序的，我们可以直接利用这个有序性，跳过$sort阶段——因为索引扫描返回的文档已经是有序的，$group可以直接按顺序合并相同值，性能会更进一步提升：

db.getCollection('data').aggregate( [
  { $cursor: {
      query: {},
      fields: { "events.hi2.ClientId": 1, "_id": 0 },
      hint: { "events.hi2.ClientId": 1 }
    }
  },
  { "$group": { "_id": "$events.hi2.ClientId" } }
], { allowDiskUse: true })

这个版本的管道完全利用索引特性，和distinct的执行逻辑几乎一致，速度会和distinct接近。

3. 针对数组字段的额外调整（如果你的需求是提取数组中所有ClientId的去重值） #

从执行计划看，events是数组（isMultiKey: true），如果你的distinct是提取所有文档中数组内所有ClientId的去重值，那你原来的聚合逻辑其实和distinct不一致——因为$group: {_id: "$events.hi2.ClientId"}会把整个数组作为分组键，而distinct会自动展开数组去重。这时候需要先$unwind数组，再分组：

db.getCollection('data').aggregate( [
  { $unwind: "$events" },
  { $match: { "events.hi2.ClientId": { $exists: true } } },
  { $cursor: {
      hint: "ClientId"
    }
  },
  { "$group": { "_id": "$events.hi2.ClientId" } }
], { allowDiskUse: true })

同样加上hint强制走索引，就能避免全表扫描。

验证效果 #

修改后你可以再跑一次执行计划，看看$cursor的winningPlan是不是变成了IXSCAN（索引扫描），而不是COLLSCAN，这样就能确认索引生效了。

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