bitcount快是因为o(1)预计算+内存位扫描，直接调用cpu的popcnt指令遍历sds缓冲区统计1的个数，无需磁盘i/o或临时表去重。
因为 BITCOUNT 是 O(1) 预计算 + 内存位扫描，而 MySQL 的 COUNT(DISTINCT user_id) 是 O(N) 磁盘行扫描 + 临时表去重
BITCOUNT 为什么快：它不查数据，只数内存里的 1
Redis 的 BITCOUNT 命令底层直接遍历字符串对象的 SDS 缓冲区，按字节查汉明重量（popcount），现代 CPU 有 POPCNT 指令，单字节只需 1 个 CPU 周期。哪怕一个 key 存了 1000 万用户状态（约 1.25MB），整个统计也控制在
对比 MySQL：
- 没有索引时，
SELECT COUNT(DISTINCT user_id) FROM dau_log WHERE dt = '20260901'必须全表扫描 + 构建哈希临时表 - 有索引也需回表或覆盖索引，但 B+ 树深度随数据增长，且并发 COUNT 容易触发行锁/间隙锁争用
- 日志表分区再大，I/O 和 buffer pool 压力仍在线性上升
Bitmap 存储密度碾压传统方案
1 个用户 = 1 bit，不是 1 行、不是 1 个 String key、也不是 1 个 Set 成员：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SETBIT active:20260901 12345678 1：用户 ID 直接当 offset，写入仅 1 bit - 1000 万用户 → 占用 ~1.25MB 内存；MySQL 同等规模至少 500MB（含主键、时间字段、索引）
- 内存带宽远高于磁盘随机读，且 Redis 全内存操作无上下文切换开销
DAU 统计场景下，Bitmap 天然支持原子聚合与时间切片
月活（MAU）不是简单加总 30 个 DAU，而是 BITOR 合并 30 个 bitmap 后再 BITCOUNT —— 整个过程在服务端完成，网络往返仅 1 次：
BITOP OR mau_202609 active:20260901 active:20260902 ... active:20260930- 命令原子执行，无需客户端加锁或事务协调
- 若用 MySQL，得 UNION ALL 30 张分区表再 DISTINCT，执行计划极易退化，超时风险高
- 更关键的是：Bitmap key 可带 TTL（如
EXPIRE active:20260901 86400），过期自动清理；MySQL 清理需定时 DELETE，容易锁表
容易被忽略的硬约束：offset 上限和 key 设计必须严谨
实际落地时，性能优势会因两个细节瞬间归零：
- 用户 ID 若为
int64且含负值，直接传给SETBIT会溢出成极大正数（如 -1 → 18446744073709551615），触发 Redis realloc 卡顿甚至 OOM - key 名若不带日期（如恒用
active），BITCOUNT扫描范围失控，百亿用户 bitmap 达 12.5GB，一次调用阻塞主线程数十毫秒 - 禁止对 bitmap key 设置长期
EXPIRE：因为SETBIT不刷新 TTL，key 会永久残留，必须靠业务侧按天生成新 key + 定时 DEL
