MongoDB复合索引下超16MB限制的UDID去重计数方案求助

遇到过不少类似大规模数据去重计数的问题，你的场景其实可以通过利用MongoDB的覆盖索引来大幅提升性能，我来一步步给你拆解最优方案：

最优解决方案：用覆盖索引优化聚合查询 #

首先得确认你的复合索引是{app: 1, udid: 1}——如果还没建的话，先执行这句创建索引：

db.sessions.createIndex({app:1, udid:1})

这个索引是整个优化的核心，它包含了我们查询需要的所有字段，能让MongoDB完全跳过文档扫描，只靠索引完成计算。

接下来用这个优化后的聚合语句：

db.sessions.aggregate([
  // 第一步：用索引快速过滤目标app的记录
  {$match: {app: ObjectId('your-app-id-here')}},
  // 第二步：只保留udid字段，明确告诉MongoDB不需要读原文档
  {$project: {_id: 0, udid: 1}},
  // 第三步：按udid分组去重
  {$group: {_id: '$udid'}},
  // 第四步：统计去重后的总数
  {$count: 'unique_udid_count'}
], {allowDiskUse: true})

为什么这个方法快很多？

• 覆盖索引加持：因为索引里已经包含了app和udid，MongoDB不需要去读集合里的实际文档，仅扫描索引就能完成全部操作，IO开销直接砍半甚至更多。
• 有序遍历降重：索引里匹配的udid是按顺序排列的，相同的udid会连续出现，MongoDB做分组去重时不用额外维护哈希表，遍历一次就能完成计数，效率比无序扫描高太多。

额外的优化小技巧

1. 验证查询计划：你可以用explain("executionStats")检查是不是真的用上了覆盖索引，如果看到executionStats.totalDocsExamined的值是0，说明完全没碰原文档，这就是最优状态：

   db.sessions.aggregate([...]).explain("executionStats")
   

2. 清理索引碎片：如果你的索引用了很久，可能存在碎片，会拖慢扫描速度。可以重建索引来优化：

   db.sessions.reIndex()
   

3. 允许磁盘临时存储：如果去重后的中间结果还是很大，加上{allowDiskUse: true}让MongoDB临时用磁盘存中间数据，避免内存不够报错。

为什么你之前的聚合慢？

你之前的语句没加$project指定只取udid，MongoDB可能会默认读取完整文档（哪怕有索引），这就导致了大量不必要的IO操作。加上$project后，MongoDB明确知道只需要索引里的udid，才会触发覆盖索引的使用，性能自然就上去了。

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