MongoDB按月分组统计的$dateToString方法

在 MongoDB 中，$dateToString 的格式化参数必须使用 C 语言风格的 %Y-%m，而非常见的 YYYY-MM。因为 %Y 代表四位年份，%m 代表补零的月份。如果误用 YYYY-MM，会导致字符串原样输出，从而使得分组统计失效。

先来说一个最常见的误区：很多开发者在用 $dateToString 做日期格式化时，习惯性地写出 YYYY-MM，结果发现分组后的字段名变成了“YYYY-MM”这个字符串本身，所有文档都被强行归入同一个假分组。原因很简单——MongoDB 的 $dateToString 并不支持 ISO 标准写法，它只认 C 语言风格的格式符。正确的写法是 "%Y-%m"，其中 %Y 输出四位年份，%m 输出补零的两位月份。

几个容易混淆的细节：

• %Y 是四位年份（如 2024），%y 是两位（24），切勿混用
• %m 是补零月份（01），Linux 风格的 %-m 在 MongoDB 中不被支持，无法去除前导零
• 如果时间字段本身是字符串而非 Date 类型，需要先用 $dateFromString 进行转换，否则 $dateToString 会直接报错，或返回 null

在聚合管道中如何安全地按月份对 created_at 字段进行分组

不能直接把原始时间戳丢进 $group 里，必须先将其标准化为“年月字符串”。关键点在于处理空值、非法日期，以及——时区问题。

一个常见的失误是忘记指定时区，导致北京时间凌晨的数据被误算到上个月。因此聚合语句中需要显式添加 timezone: "Asia/Shanghai"。另外，用 $cond 过滤掉无效的 null 或非法日期，避免干扰计数准确性。

一个典型的分组片段如下：

{
  $group: {
    _id: {
      $dateToString: {
        format: "%Y-%m",
        date: "$created_at",
        timezone: "Asia/Shanghai"
      }
    },
    count: { $sum: 1 }
  }
}

按月分组后如何排序并限制结果数量

分组后的 _id 是类似 "2024-03" 的字符串，按字典序排序即可等价于按时间先后排列。这一规律在跨年时同样成立（如 "2023-12" 小于 "2024-01"）。但请注意：如果当初格式写成了 "%m-%Y"，那么字典序就会错乱，例如 "01-2024" 会排在 "12-2023" 前面。

若要获取最近 6 个月的数据，推荐的操作顺序是：先 $group，再 $sort，最后 $limit。这个顺序不能颠倒——如果先 $limit 再分组，截断的是原始文档而非分组后的月份，结果将不符合预期。

• 升序取最近 6 个月：{$sort: {_id: 1}} + {$limit: 6}
• 降序取最近 6 个月：{$sort: {_id: -1}} + {$limit: 6}

性能隐患：索引对 $dateToString 分组是否有加速作用

答案很明确：没有。MongoDB 无法利用普通日期索引来优化 $dateToString 这种运行时计算表达式。每次分组都需要全表扫描，一旦数据量增大，性能瓶颈就会凸显。

解决思路是“空间换时间”：在写入或更新时，通过应用层或变更流同步维护一个冗余字段 year_month（例如存为 "2024-03"），然后对该字段建立索引：

db.collection.createIndex({ year_month: 1 })

这样聚合查询就可以走索引扫描，尤其是在集合庞大且只需查询最近几个月时，性能差距非常显著。当然，代价是需要维护冗余字段的一致性——如果忘记更新，统计结果就会出错，那比速度慢更严重。

归根结底，真正棘手的不是写出一个能跑的聚合语句，而是确保时间字段类型干净、时区意识明确，以及在面对百万级数据时，是否有勇气将计算逻辑从查询层迁移到写入层。