大家好，我是小耶。写功课只是为了我踩过的坑，你们别再踩了！

痛点聚焦这方面，大表去重计数的“慢”与“慢”

你一定遇到过这样的需求：“查一下昨天的独立访客数”“统计这周活跃设备量”。直接用COUNT10亿行表跑了半小时还没出结果，怎么办？

至于痛点。

• 查询时间长，业务上线受阻。
• 内存/磁盘IO压力大，影响其他查询。
• 误差容忍度不一，需要精准或近似。老实说，

去重计数的两种场景

再看方案一。近似去重—— 要快，能接受1-%误差

HyperLogLog是一种概率算法，用固定内存估算去重元素数量。说起来，原理这方面，将每个元素哈希。统计哈希值二进制表示中前导零的最大长度，通过这个信息推断去重总数。

适用场景这方面，

• UV、DAU、独立IP、搜索词去重统计等。

实现方式的观点是，

1. Redis HyperLogLog

import redis
r = redis.Redis
for user_id in logs:
r.pfadd
uv = r.pfcount # 误差1%以内

2. PostgreSQL + hll

CREATE EXTENSION hll;SELECT hll_cardinality))
FROM logs;

至于方案二，精确去重，但用索引调整 —— 要准，也要尽量快

技巧1的观点是。 覆盖索引

COUNT 只需要user_id列，如果上有索引，InnoDB可以直接扫描索引而不是全表，大大减少I/O。老实说，

-- 确保user_id有索引
CREATE INDEX idx_user_id ON logs;话说回来，SELECT COUNT FROM logs;

技巧2的观点是，使用GROUP BY代替DISTINCT

在某些数据库中。GROUP BY< /code> + 外层COUNT有时比COUNT< /code>更快：

SELECT COUNT FROM t;

至于技巧3。分桶计数

如果数据分布均匀，可以按某个维度分桶，分别计数后求和。例如按日期分区，每天分别COUNT再累加。话说回来，

方案三这方面。bitmap聚合 —— 极速精确去重

如果去重的列基数很低，可以使用bitmap。每个值对应一个bit位，多个值做OR/AND操作极快。

• '标签程序' '权限判断' '漏斗分析中的“是否完成某动作”。'
• 使用PostgreSQL的bitmap 或MySQL的SET类型。
• 适用场景这方面，
  - 标签程序
  • - 权限判断
  • - 漏斗分析中的“是否完成某动作”。

    再看方案四。预计算/物化视图 —— 以空间换时间 对于固定维度的去重统计，可以提前计算并存储结果，查询时直接读取。实现方式的观点是，

    • '每日定时任务计算前一天的COUNT存入统计表'
    • '使用物化视图'
      实时性/存储成本/适用场景对照：