接触过MongoDB聚合管道的开发者都知道，$group、$match、$project这类阶段几乎每天都会用到，但当需求变成"统计某个字段值被使用了多少次"或者"分析一段时间内资源的使用频率"时，很多人会下意识去查找有没有一个叫$usage的现成运算符。实际上，MongoDB官方文档中并不存在$usage这个聚合阶段，它更多是开发者在口头交流或内部封装时使用的概念。不过，这并不妨碍我们用标准聚合管道组合出灵活且高效的使用统计逻辑。

想要实现类似$usage的效果，第一步就是把统计需求拆解成聚合管道能够表达的原子操作。最常见的统计无非是分组计数、求和、平均值，或者按时间窗口统计频次。MongoDB为此提供了$group、$count、$sortByCount以及$bucket、$bucketAuto等阶段，这些组合起来已经能覆盖绝大多数使用统计场景。下面会从最基础的按字段值计数讲起，逐步过渡到更复杂的自定义聚合表达式，让读者彻底掌握在MongoDB中做使用统计的方法。

按字段值统计使用次数：$group与$count的配合

假设有一个用户行为日志集合events，每条文档记录了用户ID、行为类型和发生时间。如果想统计每种行为类型出现的总次数，最直接的做法就是用$group按behavior字段分组，再用$sum累加计数。代码如下：

db.events.aggregate([
  {
    $group: {
      _id: "$behavior",
      usageCount: { $sum: 1 }
    }
  },
  { $sort: { usageCount: -1 } }
])

这段管道先按behavior字段的值分组，然后对每组内的文档数进行求和，结果中的usageCount就是该行为被使用的次数。$sort阶段按使用次数降序排列，方便快速看出高频行为。如果只需要返回总文档数，可以用更轻量的$count阶段，它等价于$group加$sum但写法更简洁。不过$count不能按字段分组，它只统计整个集合或前序管道输出的文档总数。

当统计需求涉及"每个用户对每种行为的使用次数"这种多维分组时，$group的_id可以写成对象形式。例如按userId和behavior同时分组：

db.events.aggregate([
  {
    $group: {
      _id: { user: "$userId", behavior: "$behavior" },
      count: { $sum: 1 }
    }
  }
])

这种组合分组的结果会让每个用户和行为组合形成一条记录，非常适合分析用户行为画像。但要注意，如果集合数据量很大，多维分组会产生大量输出文档，建议在$group之前先用$match缩小范围，减少内存压力。

对于已经排序或需要按出现频率排名的场景，$sortByCount是更优雅的选择。它相当于在$group阶段按指定字段分组并计数，然后自动按计数降序排序。把上面的按behavior统计改写一下：

db.events.aggregate([
  { $sortByCount: "$behavior" }
])

输出结果与之前的$group加$sort完全一致，但管道更短、可读性更强。$sortByCount支持任意表达式作为参数，不限于字段路径，比如可以先把字符串转成小写再统计，这在处理大小写不一致的数据时很实用。

按时间窗口统计使用频率：$bucket与$dateTrunc的组合

使用统计往往不是单纯的总数，而是要看一段时间内的变化趋势。比如统计每天的行为使用次数，或者每小时的资源消耗量。MongoDB提供了$bucket和$bucketAuto来对连续数值进行分桶，但处理时间字段时更推荐使用$dateTrunc（4.2及以上版本支持）先把时间截断到需要的时间粒度，再用$group分组。

以下示例统计每个小时的行为使用次数，假设events集合有一个timestamp字段存储日期时间：

db.events.aggregate([
  {
    $group: {
      _id: { $dateTrunc: { date: "$timestamp", unit: "hour" } },
      usage: { $sum: 1 }
    }
  },
  { $sort: { _id: 1 } }
])

$dateTrunc会把timestamp字段截断到小时级别，所有同一小时内的文档会汇聚到同一个_id下，然后$sum统计数量。这种做法的优点是不需要预先计算时间区间，完全由数据库端完成，效率很高。如果需要按天、周、月统计，只需将unit改成day、week、month即可。

对于更复杂的时间分段需求，比如把访问时长分成0-10秒、10-60秒、60秒以上三个区间做使用统计，$bucket阶段可以派上用场。下面示例对API响应时间进行分桶计数：

db.api_logs.aggregate([
  {
    $bucket: {
      groupBy: "$responseTime",
      boundaries: [0, 10, 60, 100000],
      default: "over_100000",
      output: {
        count: { $sum: 1 },
        avgResponse: { $avg: "$responseTime" }
      }
    }
  }
])

这段代码按responseTime字段的值将文档分入不同区间，boundaries定义了上下边界，落在最后一个边界之外的文档会被归入default指定的桶。output中可以同时输出多个聚合结果，比如每个桶的文档数和平均响应时间，很适合做性能使用统计。

模拟自定义$usage操作符：聚合表达式与$accumulator

尽管没有官方的$usage阶段，但MongoDB允许通过$accumulator和$function自定义聚合逻辑，这在需要实现特定统计算法时非常有用。比如想统计每个用户最近7天的行为类型分布，并且只计算工作日的数据，标准管道很难一步到位，但自定义累加器可以解决。

下面使用$accumulator定义一个自定义累加器，模拟类似$usage的计数逻辑，只统计满足条件的文档：

db.events.aggregate([
  {
    $group: {
      _id: "$userId",
      usage: {
        $accumulator: {
          init: function() { return {}; },
          accumulate: function(state, doc) {
            if (doc.timestamp.getDay() >= 1 && doc.timestamp.getDay() <= 5) {
              state[doc.behavior] = (state[doc.behavior] || 0) + 1;
            }
            return state;
          },
          accumulateArgs: ["$timestamp", "$behavior"],
          merge: function(state1, state2) {
            for (let key in state2) {
              state1[key] = (state1[key] || 0) + state2[key];
            }
            return state1;
          },
          finalize: function(state) { return state; },
          lang: "js"
        }
      }
    }
  }
])

这个管道按userId分组，在accumulate函数里判断timestamp是否为工作日，只累加工作日的行为类型。由于使用了JavaScript，性能会比较低，只适合小数据集或低频统计场景。如果数据量很大，建议还是用原生管道组合来替代，大部分统计需求都能通过$match提前过滤实现。

对于简单的自定义统计，也可以使用$function或$expr配合$group，但本质上都是在现有阶段基础上做变通。真正高效的做法是理解聚合管道的执行顺序，把$match、$project、$limit尽可能前置，减少进入后续阶段的文档数量，这样即使是聚合大量数据也能保持良好的响应速度。

性能优化与索引建议

使用统计往往是分析型查询，对时间维度敏感时，在分组字段和时间字段上建立复合索引能显著提升聚合速度。例如经常按userId和timestamp做统计，可以为{ userId: 1, timestamp: 1 }创建索引，这样$match过滤和$group分组都能利用索引覆盖。

当聚合管道包含$group时，如果分组字段有索引，MongoDB可能会使用索引进行分组，避免全表扫描。但注意$sortByCount和$group按字段计数并不总是走索引，因为计数需要扫描所有匹配文档，但这并不代表无法优化。合理使用$match过滤后再聚合，比直接在全表上做统计快得多。另外，频繁运行相同统计逻辑时，可以考虑将结果预先计算并存储在汇总集合中，实现类似物化视图的效果。

最后提醒一点，使用统计中的"使用"一词在不同业务场景下含义不同，可能是字段出现频率、资源消耗量、接口调用次数等。无论哪一种，只要把需求转化为聚合管道中的分组、过滤、累加操作，MongoDB都能高效完成。掌握了本文介绍的$group、$count、$sortByCount、$bucket以及自定义累加器，处理大多数使用统计需求都绰绰有余。