Pymongo针对日期字段执行aggregate查询性能过慢问题咨询

问题结论 #

该性能问题是当前索引配置 + MongoDB 查询优化器逻辑下的预期行为。
核心原因是你创建的联合索引字段顺序不符合查询逻辑，且多个过期维度的索引结构高度相似：所有过期索引都将alarm_date放在最左前缀位置，当过期阈值变大时，alarm_date < 阈值匹配的文档占比升高，MongoDB 优化器会错误估算查询成本，优先选择前缀匹配的错误索引，还需要额外回表过滤状态字段，最终导致性能随数据量上涨骤降。

优化方案 #

1. 调整联合索引字段顺序（首选方案） #

遵循最左前缀匹配原则，将查询优先匹配的布尔状态字段放在索引第一位，alarm_date放在第二位，修改后的索引创建语句如下：

db.events.create_index([("exp_day_status", DESCENDING), ("alarm_date", DESCENDING)], name="exp_day")
db.events.create_index([("exp_week_status", DESCENDING), ("alarm_date", DESCENDING)], name="exp_week")
db.events.create_index([("exp_month_status", DESCENDING), ("alarm_date", DESCENDING)], name="exp_month")
db.events.create_index([("exp_months_status", DESCENDING), ("alarm_date", DESCENDING)], name="exp_months")

调整后可直接在索引层过滤掉所有已处理的、状态为True的文档，仅对未处理的文档做时间范围过滤，不需要回表额外筛选状态字段，同时也不会出现跨维度选错索引的问题。

2. 升级为覆盖索引进一步优化 #

你聚合计算仅需要exp_*_status、alarm_date、alarm_global_id、time_in_alarm四个字段，可以将后两个字段也加入索引，构成覆盖索引，完全跳过回表FETCH阶段，性能可提升50%以上：

db.events.create_index([
    ("exp_day_status", DESCENDING), 
    ("alarm_date", DESCENDING), 
    ("alarm_global_id", ASCENDING), 
    ("time_in_alarm", ASCENDING)
], name="exp_day_cover")
# 其余三个过期维度按相同规则修改索引即可

3. 强制指定索引（临时应急方案） #

如果暂时无法修改线上索引，可以在聚合查询时通过hint强制指定对应维度的索引，避免优化器选错：

db.events.aggregate([
  { "$match": {"exp_week_status":False, "alarm_date":{"$lt":time.time()-(7*60*60*24)}} },
  { "$group": {"_id": "$alarm_global_id", "time":{"$sum":"$time_in_alarm"}, "count": {"$sum":1} } }
]).hint("exp_week")

4. 清理无效索引降低写入开销 #

如果没有其他业务查询单独使用alarm_global_id单字段索引，可以直接删除该索引，减少数据写入时的索引维护成本。

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