redis hyperloglog 的标准误差率为固定0.81%，由分桶数m=16384和调和平均公式数学推导得出，与数据分布、重复率无关，是概率算法固有设计，非bug；pfmerge合并后误差仍为0.81%，不叠加。
Redis HyperLogLog 的误差不是 bug，而是设计选择：0.81% 是固定标准误差率，由分桶数 m=16384 和调和平均公式数学推导得出，无法通过重试、多插或调参消除。
误差来自概率建模，不是哈希碰撞或数据倾斜
很多人看到 PFCOUNT 返回值和真实去重数不一致，第一反应是“哈希冲突导致漏计”或“重复元素太多影响精度”。其实不是。HyperLogLog 的误差根源在算法本身——它不记录元素，只记录每个桶中哈希值的**最大前导零位数 ρ**，再用调和平均反推基数。这个过程天然带统计偏差。
关键点：
- 误差与输入数据分布无关：哪怕你
PFADD一万个相同字符串，只要 MurmurHash3 输出均匀（Redis 确保这点），误差仍稳定在 ~0.81% - 误差是相对误差：基数为 1000 时，绝对偏差约 ±8；基数为 1000 万时，绝对偏差约 ±8 万——但比例始终是 0.81%
- 重复元素完全被忽略：
PFADD key a a a和PFADD key a效果一样，不会“污染”桶状态，也不提升精度
PFMERGE 合并后误差不叠加，但有类型校验陷阱
用 PFMERGE 把多个 HLL 合并（比如按天统计后月汇总），结果的误差率仍是 ~0.81%，不是单日误差的累加。因为合并操作本质是取所有源 HLL 对应桶的 max(ρ)，再用同一套公式重算——相当于把原始数据“逻辑上投喂给一个更大的虚拟 HLL”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
但要注意实际踩坑点：
-
PFMERGE不检查键是否存在，也不做类型预判：若误传一个STRING键，直接报错WRONGTYPE Operation against a key holding the wrong kind of value - 合并后新键是全新结构，内存占用 = 所有源键中最大那个（稀疏/密集格式自动适配），不是简单相加
- 不能靠合并“修复”小基数下的波动：基数 PFCOUNT 可能返回 97 或 103，合并十个这样的键，结果还是围绕真实值 ±0.81%，不会更准
为什么非要 0.81%？内存和误差的硬性权衡
理论误差公式是 1.04 / √m。Redis 选 m = 16384（即 2^14），是因为：
-
√16384 = 128，所以1.04 / 128 ≈ 0.008125→ 0.81% - 若把
m翻倍到 32768，误差降到 ~0.57%，但内存从 ~12 KB 涨到 ~16 KB，而 UV 统计场景根本不需要这 0.24% 的提升 - 若把
m减半到 8192，误差升到 ~1.15%，内存省不了多少，却明显增加业务误判风险（比如把 99 万 UV 估成 100 万+，触发错误告警）
这个数字不是拍脑袋定的，是 Flajolet 论文推导 + Redis 工程实测后，在“12 KB 内存封顶”硬约束下找到的最优解。
真正容易被忽略的是：误差率固定，但小基数下绝对不准——比如真实基数为 12，PFCOUNT 可能返回 10 或 14，这时别硬套 0.81% 解释，该换 SET 就换；而一旦基数过万，0.81% 就成了可信赖的工程事实。
