UV超100万时应选HyperLogLog，因其仅占12KB内存，远优于Set的2.5GB；但需容忍0.81%误差，不支持交集、差集及元素反查，小数据量场景滥用反而浪费资源。
UV统计量级超过100万时，优先考虑HyperLogLog
当你要统计的是“独立访客数（UV）”这类场景，且日活/总用户量稳定在百万级以上，HyperLogLog 就不是“可选”，而是“应选”。原因很直接：1亿个字符串ID存进 Set，光原始数据就占 1.6GB+，加上Redis哈希表开销、扩容冗余、RDB/AOF备份，实际内存可能突破 2.5GB；而 HyperLogLog 固定只用 12 KB，无论你塞进去的是 100 万还是 10 亿个元素。
常见误判是“先用Set扛着，等撑不住再换”。但问题不在“能不能撑”，而在“值不值得撑”——一旦业务开始做多日UV去重、跨渠道归因或实时大盘，SCARD + SUNIONSTORE 的延迟和阻塞会立刻暴露。这时候再切，往往要改统计口径、补历史数据、协调下游系统，成本远高于初期设计时明确选型。
你需要容忍0.81%误差，且不依赖原始元素反查
HyperLogLog 不存原始值，只存概率估算状态。这意味着：
-
PFCOUNT返回的是估算值，1亿真实UV可能返回 99,190,000～100,810,000 之间的任意数 -
PFMERGE只支持并集，无法直接算交集（比如“连续两天登录用户”）或差集 - 绝对无法执行
SMEMBERS类操作——下游如果需要导出“今日活跃用户列表”或做二次标签匹配，HyperLogLog就不适用
如果你的业务逻辑里有“导出明细”“按ID查行为”“计算留存率需交集”等需求，硬上 HyperLogLog 会导致后续大量绕路方案，比如回退到两个 Set + SINTERCARD，或者引入布隆过滤器组合，反而增加复杂度。
避免在小数据量场景滥用HyperLogLog
1000个用户用 Set 可能只占几百字节，而一个 HyperLogLog 实例固定占 12 KB。这不是“省一点”，是“浪费三个数量级”。尤其在以下情况更明显：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 灰度环境或AB测试组，样本量常在千级以内
- 后台管理类接口，统计某管理员下所辖用户数（通常
- 临时调试键，比如
debug:users:20260903，生命周期短、复用率低
此时用 SADD + SCARD 更轻量、更直观，也方便用 SMEMBERS 快速核对。
注意PFADD失败却不报错的隐蔽陷阱
PFADD 返回 (integer) 0 并不总代表“已存在”，它可能意味着操作根本没生效。排查顺序建议：
- 用
redis-cli手动执行PFADD test "a"，确认返回是否为(integer) 1；如果不是，检查客户端是否传了null或空字符串（Jedis 3.x 会静默丢弃） - 执行
TYPE test，确认 key 没被其他逻辑覆盖成string类型（比如误执行了SET test "init"） - 若用了 pipeline，避免在同个 pipeline 里混用
DEL test和后续PFADD test "x"——旧版 Redis 在 pipeline 中 key 被删后，PFADD可能返回 0 且不抛异常
最稳妥的做法是：关键统计路径上，PFADD 后加一句 EXISTS 判断，或改用单命令事务（EXEC 前确保 key 状态可控）。
真正容易被忽略的不是“该不该用”，而是“什么时候不该停用Set”——比如运营同学临时要拉一份昨日新增用户ID做短信召回，这时候你得清楚知道，HyperLogLog 给不了这个能力，而保留一份短期 Set 备份的成本，可能比重构整个统计链路低得多。
