在运营小程序的过程中，用户访问数据的实时监控与分析是衡量业务健康度的关键指标。其中，UV（独立访客）和PV（页面访问量）的统计是最基础也最重要的环节。传统做法往往是每次用户点击都写入一条记录，然后通过多次数据库查询来计算去重后的UV——这种方式在用户量增长时，查询次数呈线性甚至指数级上升，既消耗资源又影响性能。

本文聚焦于云开发数据库的聚合能力，介绍如何通过一次聚合查询同时完成UV和PV的统计，并在此基础上优化数据结构，将整体数据库查询次数降低50%以上。全程提供可直接落地的代码片段与设计思路。

一、传统统计方式的痛点

在未使用聚合能力之前，常见的实现逻辑是：

1. PV统计：查询访问记录集合的总记录数，每条记录对应一次页面浏览。

2. UV统计：对访问记录集合按用户标识进行去重，计算出独立访客数。

这两个操作需要分别发起两次数据库查询。如果还需要按时间范围（如近7天、本月）、按页面路径、按用户来源等维度进行分组统计，查询次数会成倍增加。

更严重的问题是：当访问记录集合达到数十万甚至百万级时，单纯依靠count()和distinct()会面临性能瓶颈，云函数超时风险显著上升。

二、聚合框架的核心优势

云开发数据库提供的聚合能力，允许在数据库引擎内部完成数据的分组、计算、排序等操作。一次聚合请求可以完成传统方式多次查询才能实现的任务。

针对UV/PV统计，聚合框架的核心价值在于：

• 一次查询同时得到UV和PV：通过分组操作，在同一份数据上计算出总记录数（PV）和去重用户数（UV）。

• 减少数据传输：聚合在服务端完成，只返回统计结果，而不是海量原始记录。

• 支持复杂维度：按小时、天、页面、渠道等任意字段组合进行统计。

三、实战：单次聚合同时获取UV与PV

假设数据库中存在一个名为visits的集合，每条记录结构如下：

json

复制

下载

{
  "_id": "自动生成",
  "userId": "用户唯一标识",
  "pagePath": "pages/index/index",
  "visitTime": "2025-03-15T10:30:00.000Z",
  "fromSource": "share"}

3.1 基础聚合代码

以下代码实现一次性查询某天的UV和PV：

javascript

复制

下载

const cloud = require('wx-server-sdk')cloud.init()const db = cloud.database()exports.main = async (event, context) => {
  const startDate = '2025-03-15T00:00:00.000Z'
  const endDate = '2025-03-16T00:00:00.000Z'
  
  const result = await db.collection('visits')
    .aggregate()
    .match({
      visitTime: db.command.gte(startDate).and(db.command.lt(endDate))
    })
    .group({
      _id: null,
      pv: db.aggregate.sum(1),
      uv: db.aggregate.addToSet('$userId')
    })
    .project({
      pv: 1,
      uv: db.aggregate.size('$uv')
    })
    .end()
  
  return result.list[0] || { pv: 0, uv: 0 }}

代码解析：

• match阶段：筛选出指定时间范围内的访问记录。

• group阶段：_id: null表示对所有记录进行全局分组。pv通过sum(1)累计记录总数。uv通过addToSet将每个用户的ID加入一个去重集合。

• project阶段：保留pv字段，并用size计算uv集合的长度，即独立访客数。

关键优化点：一次聚合调用完成两个指标统计，原本需要两次查询，现在只需一次。查询次数降低50%。

3.2 按页面路径分组统计

如果希望看到每个页面的PV和UV，只需修改_id字段：

javascript

复制

下载

const result = await db.collection('visits')
  .aggregate()
  .match({ /* 时间筛选 */ })
  .group({
    _id: '$pagePath',           // 按页面路径分组
    pv: db.aggregate.sum(1),
    uv: db.aggregate.addToSet('$userId')
  })
  .project({
    pagePath: '$_id',
    pv: 1,
    uv: db.aggregate.size('$uv')
  })
  .end()

返回结果示例：

json

复制

下载

[
  { "pagePath": "pages/index/index", "pv": 1250, "uv": 320 },
  { "pagePath": "pages/detail/detail", "pv": 890, "uv": 210 }]

同样的查询次数，现在同时获得了所有页面的详细数据。

四、进阶优化：预聚合机制进一步降低查询

尽管聚合能减少单次统计的查询次数，但如果频繁请求（例如用户每次进入后台首页都实时聚合整个集合），数据库压力仍然较大。更彻底的方案是引入预聚合。

4.1 设计预聚合集合

创建dailyStats集合，按天存储已经计算好的统计结果：

json

复制

下载

{
  "_id": "2025-03-15",
  "totalPv": 36400,
  "totalUv": 5200,
  "pages": {
    "pages/index/index": { "pv": 12500, "uv": 3100 },
    "pages/detail/detail": { "pv": 8900, "uv": 1800 }
  },
  "sources": {
    "share": { "pv": 12000, "uv": 2200 },
    "direct": { "pv": 15000, "uv": 2500 }
  }}

4.2 定时任务生成预聚合数据

创建一个定时触发的云函数（如每天凌晨执行），对前一天的原始数据进行聚合，将结果写入dailyStats：

javascript

复制

下载

// 每日统计云函数exports.main = async (event, context) => {
  const targetDate = getYesterday()  // 计算前一天的日期范围
  
  const aggResult = await db.collection('visits')
    .aggregate()
    .match({ visitTime: targetDate.range })
    .group({
      _id: null,
      totalPv: db.aggregate.sum(1),
      totalUvSet: db.aggregate.addToSet('$userId'),
      pageStats: db.aggregate.push({
        pagePath: '$pagePath',
        userId: '$userId'
      })
    })
    .end()
  
  // 这里需要更精细的分组计算，实际实现中可能需要多次聚合或云函数内二次处理
  // 将最终结果写入 dailyStats 集合
  await db.collection('dailyStats').add({
    data: {
      _id: targetDate.dateStr,
      totalPv: aggResult.list[0].totalPv,
      totalUv: aggResult.list[0].totalUvSet.length,
      // ... 页面维度统计
    }
  })}

4.3 查询时直接读取预聚合结果

当需要展示某天的统计数据时，不再查询visits集合，直接读取dailyStats文档：

javascript

复制

下载

const statDoc = await db.collection('dailyStats').doc('2025-03-15').get()// 一次读取完成，零计算消耗

效果对比：

预聚合将实时计算转化为读取操作，在高频访问的仪表盘场景下，数据库查询次数可降低90%以上，结合基础聚合带来的50%下降，整体优化幅度非常可观。

五、注意事项与最佳实践

5.1 聚合性能边界

• 单次聚合处理的数据量建议控制在10万条以内，超过此量级应考虑时间分片或预聚合。

• addToSet在数据量极大时会产生较大内存开销。对于UV统计，可改用$group配合$first的分桶策略，或使用基数估算方法。

5.2 索引设计

在visits集合上，务必对以下字段建立索引，以加速match阶段：

• visitTime：单字段索引（时间范围查询必备）

• 复合索引：{ visitTime: -1, pagePath: 1 }（按时间+页面查询时使用）

5.3 用户标识的选取

不建议直接使用用户的openId进行addToSet去重，原因有二：

1. 隐私合规：聚合结果中不应暴露用户原始标识。

2. 性能：openId是字符串，作为集合元素性能不如整型。

推荐方案：在写入访问记录时，为每个用户分配一个自增或哈希后的整型userId（内部使用，不对外暴露）。

5.4 实时统计与离线统计的平衡

• 实时统计（近5分钟内）：使用聚合match最近时间范围，可容忍一定延迟。

• 准实时统计（当天累计）：使用预聚合 + 实时增量更新的混合策略。

• 历史统计（昨天及以前）：完全依赖预聚合。

六、总结

通过云开发数据库聚合能力的合理运用，统计小程序UV/PV不再需要多次查询。一个聚合请求即可同时获得独立访客数和页面访问量，单次统计的数据库查询次数减少50%。在此基础上引入预聚合机制，将历史数据固化存储，查询操作进一步降级为单文档读取，整体资源消耗大幅下降。

实践中可以根据业务需求选择不同方案：

• 中小规模流量：直接使用聚合查询，简单高效。

• 大规模或高频查询场景：聚合 + 预聚合组合，实现性能与成本的双重优化。

这种设计思路不只适用于UV/PV统计，任何需要分组、去重、计数的数据分析场景都可以借鉴。掌握聚合框架，意味着能用更少的资源做更多的事情。