MongoDB 查询优化方案（提高并发性能）

下面对给定聚合进行诊断并给出可直接应用的优化方案，包括索引设计、查询改写与执行参数调整，重点针对并发性能与总体吞吐量提升。

1. 诊断与瓶颈定位

• 当前查询：
  • $match：按 ts 月度范围 + eventType IN 过滤
  • $group：按 userId 聚合计数和 max(ts)
  • $sort + $limit：Top 100 用户
• 现有索引：单字段 {userId:1}、{ts:1}
• 主要瓶颈：
  • $match 无法使用有效的复合索引：若仅用 {ts:1}，会在整个月 ts 范围内扫描大量键，再在执行器中过滤 eventType，增加 I/O 与 CPU，影响并发。
  • $group 需对大量文档按 userId 聚合，受前置过滤效率影响显著；同时内存占用与并发冲突风险上升。
  • $sort + $limit 属于 Top-N 排序，MongoDB 已自动做“受限排序”优化，但能否早期收敛取决于上游缩减量。

并发下的关键目标是：最大程度将过滤下推到索引、减少扫描量和FETCH次数、降低分组内存与I/O，从而缩短持有资源的时间。

2. 核心优化策略

A. 建立覆盖的复合索引（eventType, ts, userId）

• 建议索引（全量或部分，二选一）：
  • 全量复合索引：

    db.actions.createIndex(
      { eventType: 1, ts: 1, userId: 1 },
      { name: "evt_ts_user_cover" }
    )
    

  • 部分（Partial）索引（仅覆盖 login/view/purchase）：

    db.actions.createIndex(
      { eventType: 1, ts: 1, userId: 1 },
      {
        name: "evt_ts_user_cover_partial",
        partialFilterExpression: { eventType: { $in: ["login", "view", "purchase"] } }
      }
    )
    

• 原理与理由：
  • 将等值（$in 多等值）列 eventType 放在前，范围列 ts 放在后，满足“等值优先、范围随后”的索引设计原则，形成紧致的多段范围扫描（每个 eventType 一个 ts 范围）。
  • 将 group 的键（userId）包含在索引尾部，使扫描只读取索引键即可满足后续计算，最大化“覆盖查询”收益，减少文档FETCH。
• 性能影响：
  • 执行时间：大幅下降（通常可减少扫描键数量到原来的 5%～30%，取决于事件分布与选择性）。
  • 资源使用：降低磁盘/缓存 I/O；减少 WiredTiger 锁/闩占用时间；CPU 降低（过滤在索引端完成）。
  • 并发影响：缩短每个查询持有资源的时间，吞吐量提高；部分索引还减少写入索引维护开销，降低写-读争用。

选择全量 vs 部分索引：如果查询只关心 login/view/purchase，优先使用部分索引，体积更小、维护成本更低；如果还会查询其他 eventType，再使用全量索引。

B. 改写 $match 以形成更好的索引区间（可选但常见有效）

将 $in 改写为 $or 的多个子谓词，可使优化器构造更明确的多分支范围扫描（通常与复合索引配合能得到更紧的边界）：

{ $match: {
    $or: [
      { eventType: "login",    ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
      { eventType: "view",     ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
      { eventType: "purchase", ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } }
    ]
} }

• 性能影响：
  • 执行时间：在数据分布不均或优化器不能完美展开 $in 的版本中，常有 5%～15% 的提升。
  • 资源：略降扫描键与分支合并成本。
• 并发：略缩短单次查询时间，边际提升吞吐。

C. 在 $match 后显式 $project 仅保留需要字段（userId, ts）

{ $project: { _id: 0, userId: 1, ts: 1 } }

• 原理：
  • 聚合管线只传递和分组所需字段，减少内存与执行层数据拷贝。
  • 若已使用覆盖索引，上述字段均来自索引，进一步减少FETCH。
• 性能影响：
  • 执行时间：中等规模（10万～100万行）通常 5%～10% 改善。
  • 资源：管线中间态内存与网络开销下降（若有）。

D. 在 aggregate 中使用 hint 指向复合索引

{ hint: "evt_ts_user_cover_partial" }  // 或 { eventType:1, ts:1, userId:1 }

• 原理：
  • 确保优化器选用预期的最优索引，避免退回单列 {ts:1} 的宽范围扫描。
• 性能/并发影响：
  • 稳定性提升，避免在负载或统计波动下出现退化计划，提升 tail latency（长尾延迟）。

E. 启用 allowDiskUse（保护并发稳定性）

• 在可能有较大去重用户集的月份，$group 内存使用可能接近上限。为避免内存压力影响其他并发查询，可启用 allowDiskUse。
• 取舍：
  • 执行时间：若确实溢写到磁盘，单次查询会略慢，但长尾抖动与因内存压力导致的抖动/失败大幅降低。
  • 并发：避免内存争用，提升整体稳定性与吞吐稳定性。

F. 读选项（可选）：读偏好与 readConcern

• 若允许弱一致性：
  • 使用 readPreference: "secondary" 将读压从主节点分流。
  • readConcern: "local"（默认）即可，减少复制障碍对读延迟影响。
• 并发影响：
  • 横向分摊读负载，显著提升并发吞吐；对实时性强的场景谨慎使用 secondary。

G. 结构性优化（中长期）：预聚合/物化视图

对月度 Top-100 的类报表查询，采用“按天按用户聚合”的物化表，运行时只需对日级摘要再聚合：

• 日表结构：user_event_daily(userId, day, cnt, lastSeen)
• 每日/流式汇总后，月度查询只扫描 ≤ 用户数 × 30 的记录，大幅减少扫描量与分组内存。
• 并发影响：
  • 在线查询耗时与资源占用剧降，适合高并发场景。
  • 写端增加少量聚合/合并开销（可用定时批/流式Change Stream补数）。

3. 可直接使用的优化后查询示例

3.1 建索引（推荐：部分索引覆盖 login/view/purchase）

// 仅对 login/view/purchase 建立部分覆盖索引（更小，更快，更少写入开销）
db.actions.createIndex(
  { eventType: 1, ts: 1, userId: 1 },
  {
    name: "evt_ts_user_cover_partial",
    partialFilterExpression: { eventType: { $in: ["login", "view", "purchase"] } }
  }
);

或，如需覆盖所有事件类型：

db.actions.createIndex(
  { eventType: 1, ts: 1, userId: 1 },
  { name: "evt_ts_user_cover" }
);

3.2 优化后的聚合管线（改写 $match + 覆盖索引 + hint + allowDiskUse）

db.actions.aggregate(
[
  {
    $match: {
      $or: [
        { eventType: "login",    ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
        { eventType: "view",     ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
        { eventType: "purchase", ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } }
      ]
    }
  },
  // 仅保留后续需要的字段，配合覆盖索引减少FETCH与内存传递
  { $project: { _id: 0, userId: 1, ts: 1 } },
  // 按用户聚合
  { $group: { _id: "$userId", evt_cnt: { $sum: 1 }, lastSeen: { $max: "$ts" } } },
  // Top-N 排序 + 限制
  { $sort: { evt_cnt: -1, lastSeen: -1 } },
  { $limit: 100 }
],
{
  allowDiskUse: true,
  hint: "evt_ts_user_cover_partial" // 或 { eventType:1, ts:1, userId:1 }
}
);

如果不想改写为 $or，仍可沿用 $in，但保留其他优化：

db.actions.aggregate(
[
  {
    $match: {
      ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") },
      eventType: { $in: ["login","view","purchase"] }
    }
  },
  { $project: { _id: 0, userId: 1, ts: 1 } },
  { $group: { _id: "$userId", evt_cnt: { $sum: 1 }, lastSeen: { $max: "$ts" } } },
  { $sort: { evt_cnt: -1, lastSeen: -1 } },
  { $limit: 100 }
],
{
  allowDiskUse: true,
  hint: { eventType: 1, ts: 1, userId: 1 }
}
);

3.3 可选：将查询定向至从节点（允许弱一致时）

db.getMongo().setReadPref("secondary"); // 会话级
// 或在驱动层设置 readPreference=secondary

4. 性能影响分析（逐项）

• 覆盖复合索引 {eventType:1, ts:1, userId:1}
  • 执行时间：过滤在索引端完成；通常扫描量显著下降；Top-N 排序前的输入规模减少，整体端到端延迟降低。
  • 资源：减少磁盘与缓存I/O、降低FETCH，CPU下降；并发冲突概率降低。
• 部分索引
  • 执行时间：同上；因索引更小，遍历更快。
  • 资源：索引体积缩小，B-Tree 更浅；写入时仅维护一棵小索引；读写争用降低。
• $or 改写
  • 执行时间：在某些版本/分布中减少额外过滤成本，改善 5%～15%。
  • 资源：略降。
• $project 精简列
  • 执行时间：减少管线数据体积，常见 5%～10%。
  • 资源：内存与拷贝压力下降。
• hint 固定计划
  • 执行时间：避免退化；尤其在统计波动时稳定尾延迟。
  • 资源/并发：计划稳定减少不必要资源消耗。
• allowDiskUse
  • 执行时间：可能略增单次耗时（如果发生溢写），但避免内存爆与抖动。
  • 并发：显著提升稳定性，避免因少数大查询挤压内存影响其他会话。

5. 中长期扩展：预聚合示例（提升高并发下的整体吞吐）

每日聚合流水（可定时任务），将原始 actions 汇总到 user_event_daily：

// 以天为粒度预聚合（可每日跑一次，或滚动窗口）
db.actions.aggregate([
  {
    $match: {
      ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-12-01") },
      eventType: { $in: ["login","view","purchase"] }
    }
  },
  { $project: { userId: 1, day: { $dateTrunc: { date: "$ts", unit: "day" } }, ts: 1 } },
  {
    $group: {
      _id: { userId: "$userId", day: "$day" },
      cnt: { $sum: 1 },
      lastSeen: { $max: "$ts" }
    }
  },
  {
    $merge: {
      into: "user_event_daily",
      on: ["_id"],
      whenMatched: "merge",
      whenNotMatched: "insert"
    }
  }
], { allowDiskUse: true, hint: { eventType: 1, ts: 1, userId: 1 } });

月度 Top-100 查询只需对日表聚合：

db.user_event_daily.aggregate([
  { $match: { "_id.day": { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-12-01") } } },
  {
    $group: {
      _id: "$_id.userId",
      evt_cnt: { $sum: "$cnt" },
      lastSeen: { $max: "$lastSeen" }
    }
  },
  { $sort: { evt_cnt: -1, lastSeen: -1 } },
  { $limit: 100 }
], { allowDiskUse: true });

• 效果：运行时扫描规模从“月内所有事件条数”降为“日汇总记录数”（约 用户数 × 30），在高并发下具有数量级的性能优势。

6. 分片（如需横向扩展并发）

• 若未来数据/并发继续增长，建议分片：
  • 读为主、按时间范围查询：range 分片键 { ts: 1 } 能将查询路由到时间范围覆盖的部分分片，减少跨分片扫描。
  • 写入和用户维度均衡：可考虑 { userId: "hashed" } 保证写均衡；但本查询按 ts 查询时会触发跨分片读（换取高并发吞吐与分布式并行）。
• 注意：选择分片键需平衡路由精确性与写热点，生产中应结合业务写入/读取模式与分布情况评估。

7. 最终建议清单（可复用）

1. 建立覆盖复合索引：{eventType:1, ts:1, userId:1}（优先部分索引）。
2. 将 $match 改写为 $or（可选）以强化多段索引范围。
3. 在 $match 后增加 $project，仅保留 userId、ts。
4. aggregate 使用 hint 指向复合索引；开启 allowDiskUse 保障并发稳定性。
5. 若可接受弱一致，将读定向 secondary。
6. 中长期采用日级预聚合，显著降低在线查询压力；必要时引入分片。

以上优化可在中型数据量（1万～100万）下带来显著并发性能提升与更稳定的尾延迟表现，且兼顾后续规模扩展。