HyperLogLog 最迷人的地方，是它能用很小的空间估算海量 UV。也正因为这个特性，它常被误用成「低成本去重集合」。
关键区别在于：Set 保存成员，所以能判断某个用户是否出现过；HyperLogLog 不保存成员，只保存一组统计寄存器，所以只能回答大概有多少个不同元素。
先把机制边界说清楚
这一篇只讨论基数估算。只要你的业务需要精确成员、可回溯明细、计费或风控判断，HyperLogLog 就不是正确工具。
整体路径
上面这张图先把主线铺开：用哈希尾部零分布估算不同元素数量。所以 HLL 的判断重点不在命令，而在它牺牲了「查成员」能力换来了极小的固定内存。
底层机制
- 元素先被哈希，哈希的一部分决定寄存器桶，另一部分用于观察前导零或尾部零模式。
- 每个桶只保留观测到的最大值，不保存原始元素。
PFMERGE可以合并多个 HyperLogLog，适合跨天或跨业务维度统计。- 估算有误差，且误差不是 bug，而是算法用空间换精度的结果。Redis HyperLogLog 的密集表示最多约 12KB，低基数时会先用更小的稀疏表示，不要答成“永远固定 12KB”。
这些机制放在一起看，就能理解 HLL 为什么用约 12KB 就能估算上亿 UV，以及它为什么永远查不了「某个用户来没来过」。
取舍与边界
HyperLogLog 的边界是「我只关心数量，而且能接受误差」。一旦要查成员是否存在，就应该换 Set、Bitmap 或明细表。
典型问题：用机制化例子排查
- UV、独立设备数、粗粒度曝光去重适合 HyperLogLog。
- 会员资格、优惠券领取、风控黑名单不能用它做最终判断。
- 上线前用真实样本对比精确 Set，确认误差是否在业务可接受范围。
- 按日期或活动拆 key，后续用
PFMERGE汇总，避免统计口径混乱。
收束：一句判断
HyperLogLog 不是小号 Set，而是一个只回答「大概多少」的统计器。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
