PFMERGE 能合并多天 UV 数据，但要求所有 key 均为合法 HyperLogLog 类型；否则报 WRONGTYPE 错误，空 key 被静默忽略；需用 PFADD 初始化、禁用自定义精度、避免手动序列化，并控制单次合并 key 数≤32。
PFMERGE 能不能直接合并多天的 UV 数据
能，但必须确保所有参与合并的 key 都是合法的 HyperLogLog 类型值。如果其中任意一个 key 是字符串、哈希或空值，PFMERGE 会直接报错：WRONGTYPE Operation against a key holding the wrong kind of value。
常见错误现象：某天漏了初始化，用 SET 写了个默认值进去，第二天跑 PFMERGE 就崩了；或者用 DEL 清过 key，但没重 PFADD，导致 key 不存在 —— 这种情况 PFMERGE 会静默忽略该 key（不报错，但结果少算）。
- 务必在每天首次写入前，用
EXISTS或TYPE检查 key 类型，或统一用PFADD初始化（它对不存在的 key 会自动创建 HLL 结构） - 不要依赖
DEL后再重建，改用PEXPIRE设置过期时间更安全 -
PFMERGE不支持通配符，必须显式列出所有要合并的 key，比如：PFMERGE uv:week1 uv:20240401 uv:20240402 uv:20240403
合并后结果不准？检查是否混用了不同精度的 HLL
Redis 的 HyperLogLog 默认使用 14 位寄存器（m = 16384），误差率约 0.81%。但如果你用客户端库手动构造了非标准参数的 HLL 值（比如某些 Go 客户端支持自定义 p 值），再塞进 Redis，PFMERGE 会拒绝合并并报错：ERR Invalid HyperLogLog key。
根本原因：Redis 只认自己生成的 HLL 编码格式（0x01 header + 14-bit 寄存器），其他格式一律视为非法。
- 所有数据必须由 Redis 自身的
PFADD写入，避免用SET+ 手动序列化 HLL 字节数组 - 跨服务写入时，确认各语言客户端都禁用了自定义精度（如 Jedis 默认 OK，而某些 Rust crate 可能默认改
p） - 用
DEBUG OBJECT <key></key>查看内部编码，合法 HLL 的encoding应为raw或embstr，且serializedlength接近 12600 字节（16384/8 + header）
合并大量天粒度 key 时卡顿或超时
PFMERGE 是阻塞命令，时间复杂度为 O(N)，N 是所有输入 key 的寄存器总数（每个 HLL 固定 16384 个 6-bit 计数器）。合并 7 天就是 7 × 16384 ≈ 11.5 万次位操作 —— 对 Redis 来说很轻量，但如果一次合并上百个 key（比如按小时聚合再合周），就会明显拖慢主线程。
更危险的是网络层：客户端发一个超长命令（如 200 个 key 名拼成的字符串），可能触发 Redis 的 proto-max-bulk-len 限制或客户端缓冲区溢出。
- 单次
PFMERGE最好不超过 32 个 key；超过就分批，比如先两两合并成中间 key，再归并 - 避免在高峰时段执行，可用
CLIENT PAUSE短暂阻塞新请求，降低影响 - 用
redis-cli --pipe批量提交时，确保每行命令长度
合并完怎么验证结果是否合理
不能只比对 PFCOUNT 数值，因为 HLL 本身是概率算法，相同数据多次合并结果也可能有微小浮动（±1% 内都正常）。重点看逻辑一致性：
- 用
EXISTS确认目标 key 已生成，且TYPE返回string（HLL 在 Redis 中底层是字符串编码） - 对比合并前后各天的
PFCOUNT总和与最终值：若最终值远小于总和（比如差 50%），说明有 key 类型错误或被静默跳过 - 抽样验证：选一天的数据，用
PFADD单独往新 key 加一遍，再和合并结果比对，偏差应
最易被忽略的一点：PFMERGE 不会自动清理源 key，合并后它们仍占内存。如果只是临时聚合，记得在确认无误后 DEL 掉中间 key，否则几天下来内存悄悄翻倍。
