嘿，我来帮你搞定这个MongoDB百万级数据的聚合超时问题！针对你的场景，我整理了几个核心优化方向，结合你的查询和文档结构来具体说明：

一、先给关键字段加索引——这是解决超时的核心 #

大数据量下，没有索引的话Mongo会做全表扫描，速度肯定慢到超时。你需要给两个集合都创建针对性的复合索引：

1. 主集合（你执行第一个$match的集合）的索引 #

第一个$match用到了offerCheckedDate、offerAvailable、channelId，后续还要用到mobile做关联，所以建一个覆盖这些字段的复合索引：

db.your_main_collection.createIndex({
  offerCheckedDate: 1,
  offerAvailable: 1,
  channelId: 1,
  mobile: 1
})

注意把your_main_collection换成你实际的集合名

2. PA_DATA_REPORTING集合的索引 #

这个集合需要匹配mobile（关联字段）、customAppliedDate（过滤字段），还要判断financierId和appliedFinancierId是否相等，所以建复合索引覆盖这些字段：

db.PA_DATA_REPORTING.createIndex({
  mobile: 1,
  customAppliedDate: 1,
  financierId: 1,
  appliedFinancierId: 1
})

二、重构聚合管道，减少不必要的处理阶段 #

你的原始管道有不少冗余步骤，比如先$group存mobile到数组再$unwind，完全可以简化；另外把更多过滤逻辑提前到$lookup内部，减少跨集合传输的数据量。这里给你优化后的完整管道：

[
  // 第一步：过滤主集合数据，保留符合条件的记录
  {
    $match: {
      offerCheckedDate: {
        $gte: ISODate("2022-11-14T00:00:00.000Z"),
        $lt: ISODate("2022-12-20T00:00:00.000Z")
      },
      offerAvailable: "YES",
      channelId: { $in: [1000001, 1000000] }
    }
  },
  // 简化去重：直接按mobile分组，_id就是唯一的mobile，不需要$addToSet和$unwind
  { $group: { _id: "$mobile" } },
  // 优化lookup：把后续的过滤、判断逻辑都放进内部pipeline，提前过滤无效数据
  {
    $lookup: {
      from: "PA_DATA_REPORTING",
      localField: "_id",
      foreignField: "mobile",
      pipeline: [
        // 先过滤customAppliedDate符合条件的记录
        {
          $match: {
            customAppliedDate: {
              $gte: ISODate("2022-11-14T00:00:00.000Z"),
              $lt: ISODate("2022-11-20T00:00:00.000Z")
            }
          }
        },
        // 直接判断financierId和appliedFinancierId是否相等，过滤掉不符合的
        { $match: { $expr: { $eq: ["$financierId", "$appliedFinancierId"] } } },
        // 只保留后续统计需要的字段，减少数据传输量
        { $project: { mobile: 1, financierId: 1 } }
      ],
      as: "paData"
    }
  },
  // 展开lookup结果，同时排除没有匹配上的记录（preserveNullAndEmptyArrays: false）
  { $unwind: { path: "$paData", preserveNullAndEmptyArrays: false } },
  // 最后按financierId分组统计mobile数量
  {
    $group: {
      _id: "$paData.financierId",
      mobileCount: { $sum: 1 }
    }
  }
]

优化点说明： #

• 去掉了冗余的$addToSet和$unwind：直接用$group {_id: "$mobile"}就能得到唯一的mobile列表，减少两个处理阶段
• 把customAppliedDate过滤和financierId/appliedFinancierId相等判断放进$lookup的内部pipeline：这样在关联的时候就直接过滤掉无效数据，不会把大量无用数据拉到主管道里处理
• 提前$project只保留需要的字段：减少跨集合传输的数据大小，提升速度

三、临时调整Mongo Compass的超时时间（应急方案） #

如果优化后还是超时，可以先调整Compass的聚合查询超时设置：

1. 打开Mongo Compass，点击左上角的MongoDB Compass菜单，选择Settings
2. 在General选项里找到Aggregation Timeout，把默认的30秒改成更长的时间（比如60秒或120秒）

这只是临时方案，核心还是要靠索引和管道优化

四、用explain()排查瓶颈 #

你可以用explain()查看聚合的执行计划，确认索引是否生效：

db.your_main_collection.aggregate([/* 你的聚合管道 */]).explain("executionStats")

查看结果里的executionStats部分，如果看到totalDocsExamined远小于你的总数据量（110万），说明索引生效了；如果还是接近110万，那可能是索引没建对或者没被用到，需要调整索引。

你可以先按上面的步骤试试，应该能明显提升查询速度，解决超时问题~

备注：内容来源于stack exchange，提问作者Sanjeev