如何优化MongoDB 1700万文档分组聚合查询性能？

问题根源分析 #

你的聚合查询耗时久的核心原因包括：

1. 单独的单字段索引无法覆盖聚合需求，MongoDB只能执行全文档扫描，加载40个字段的完整文档，IO开销极大。
2. 默认100MB的聚合内存限制很可能被突破，导致MongoDB使用磁盘临时文件存储中间结果，大幅拖慢速度（可通过db.collection.aggregate([...], {explain: true})查看executionStats.hasStageUsingDisk验证，若为true则确认是磁盘IO导致）。

优化方案（按优先级排序） #

1. 创建覆盖复合索引 #

针对聚合用到的State、Latitude、Longitude三个字段，创建复合索引，让MongoDB直接从索引中读取数据，无需加载完整文档：

db.collection.createIndex({State: 1, Latitude: 1, Longitude: 1})

• 按State排序的索引可以让MongoDB在扫描时按分组键有序读取，减少内存中分组的计算开销。
• 创建完成后，通过explain确认聚合是否走IXSCAN（索引扫描）而非COLLSCAN（全表扫描）。

2. 使用物化视图（最优解，适合Web API场景） #

由于你的查询无过滤条件，结果是固定维度的分组统计，物化视图可以预先计算并存储结果，查询时直接读取预计算数据，耗时可降至毫秒级：

创建物化视图

db.createCollection("state_stats", {
  viewOn: "collection", // 替换为你的原集合名
  pipeline: [
    {$group: {
      _id: "$State",
      avgLat: {$avg: "$Latitude"},
      avgLon: {$avg: "$Longitude"},
      count: {$sum: 1}
    }}
  ]
})

刷新视图

• 若数据更新不频繁，可手动刷新：

db.runCommand({refreshMaterializedView: "state_stats"})

• 若需要准实时结果，可通过MongoDB定时任务（或外部调度工具如Cron）定期执行刷新命令。
• Web API直接查询物化视图：db.state_stats.find()即可获取统计结果。

3. 调整聚合内存限制 #

修改MongoDB的聚合内存限制，避免使用磁盘临时文件：

运行时临时调整

db.adminCommand({setParameter: 1, aggregationMemoryLimit: 2147483648}) // 设置为2GB

永久配置（修改mongod.conf）

setParameter:
  aggregationMemoryLimit: 2147483648

• 调整值需根据服务器内存情况设定，建议不超过物理内存的50%。

4. 优化服务器与MongoDB配置 #

• 升级磁盘为SSD：机械磁盘的随机IO性能是瓶颈，SSD可将全表扫描速度提升数倍。
• 调整WiredTiger缓存：在mongod.conf中增大缓存，让更多数据驻留内存：

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 20 # 若服务器内存≥32GB，建议设置为20GB左右

• 避免资源竞争：确保MongoDB服务器无其他高IO/CPU的进程运行，优先保障聚合任务的资源。

5. 架构层面优化（可选） #

若数据量持续增长，可考虑搭建MongoDB分片集群，将数据分散到多个节点，并行执行聚合任务，进一步提升性能。

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