求助：MongoDB数组内对象索引优化，聚合查询过慢如何解决

一、先简化聚合管道 #

先确认你的聚合管道是否是最简结构——如果只是统计不同value的数量，不需要额外字段的话，基础管道应该是这样：

db.collection.aggregate([
  { $unwind: "$values" },
  { $group: { _id: "$values.value", count: { $sum: 1 } } }
])

如果管道里有多余的阶段（比如无意义的$project、未过滤的$match），直接删掉，减少不必要的数据处理量。

二、正确创建多键索引 #

你之前索引无效，大概率是没建对类型。针对嵌套数组里的value字段，需要创建多键索引：

db.collection.createIndex({ "values.value": 1 })

如果你的聚合需要先过滤文档（比如按name筛选），可以建复合多键索引（注意：复合多键索引只能包含一个数组字段）：

db.collection.createIndex({ "name": 1, "values.value": 1 })

多键索引能优化前置的$match阶段，减少进入$unwind的数据量，但对纯$unwind+$group的直接加速有限，重点还是要配合过滤逻辑。

三、先过滤再聚合（必做优化） #

如果不需要统计所有6000个文档，一定要在聚合最前面加$match过滤掉无关文档，比如只统计name为test的文档：

db.collection.aggregate([
  { $match: { name: "test" } }, // 先过滤，大幅减少后续unwind的数据量
  { $unwind: "$values" },
  { $group: { _id: "$values.value", count: { $sum: 1 } } }
])

这一步能直接砍掉大部分待处理数据，是见效最快的优化手段。

四、用$reduce替代全量unwind（内存友好方案） #

如果你的MongoDB版本是4.4+，推荐用$reduce在单个文档内部先完成value计数，再全局聚合，彻底避免生成3200万条中间文档：

db.collection.aggregate([
  // 单个文档内先统计各value的出现次数
  {
    $addFields: {
      valueCounts: {
        $reduce: {
          input: "$values",
          initialValue: {},
          in: {
            $mergeObjects: [
              "$$value",
              {
                $arrayToObject: [[
                  { k: "$$this.value", v: { $add: [ { $ifNull: [ "$$value.$$this.value", 0 ] }, 1 ] } }
                ]]
              }
            ]
          }
        }
      }
    }
  },
  // 将文档内的统计结果拆为键值对
  { $unwind: { path: { $objectToArray: "$valueCounts" } } },
  // 全局聚合合并总数
  { $group: { _id: "$k", count: { $sum: "$v" } } }
])

这个方案把数据处理压力从全局聚合转移到单文档内部，性能提升非常明显。

五、硬件与配置调优 #

• 确保MongoDB有足够内存，让工作集能完全装入内存（3200万条数据建议至少16G以上内存），避免频繁磁盘IO；
• 调整WiredTiger缓存大小（默认是系统内存的50%），可以在配置文件中设置wiredTigerCacheSizeGB；
• 如果是副本集，将读请求路由到从节点，分摊主节点压力。

六、预计算（高频查询终极方案） #

如果这个统计是高频操作，直接预计算结果：

• 新建一个value_stats集合，存储每个value的实时总数；
• 每次插入/更新文档时，遍历values数组，对每个value执行：

  db.value_stats.updateOne({ _id: value }, { $inc: { count: 1 } }, { upsert: true })
  

• 查询时直接从value_stats读取，耗时毫秒级。

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