HyperLogLog 不会被内存淘汰策略主动淘汰，其底层以 String 编码存储（固定约12KB），淘汰仅针对整个 key，而非内部结构；它与其他 key 一样参与 LRU/LFU 竞争，但因体积小、常无 TTL、多用于长期统计，实际被淘汰概率极低。
不会。HyperLogLog 本身不会被内存淘汰策略主动淘汰。
Redis 内存淘汰不作用于 HyperLogLog 的内部结构
HyperLogLog 在 Redis 中底层以 String 编码存储（实际是固定 12KB 的字节数组），但它不是普通 key-value 对中的 “value” 类型意义上的字符串——它是一个逻辑独立的、带语义的数据结构。Redis 的内存淘汰策略（如 allkeys-lru、volatile-lfu 等）只对整个 key 进行判断和驱逐，而判断依据是该 key 的 访问时间 或 访问频次，不是它的内部数据类型。
也就是说：PFCOUNT 或 PFADD 操作不会更新 key 的 LRU/LFU 时间戳；Redis 不会因为某个 key 是 HyperLogLog 就给它“特殊照顾”或“特殊歧视”。它和其他 String key 一样参与淘汰竞争，但淘汰的是整个 key，不是“把 HLL 里的一部分桶删掉”。
常见误解来源：看到 INFO memory 中 used_memory_dataset 包含了 HLL 占用的 12KB，就以为它会被按“数据内容”拆解淘汰——实际上不会。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么你很少见到 HLL key 被淘汰？
- HyperLogLog 通常用于长期统计场景（如每日 UV、设备去重 ID），key 名往往带日期或业务维度（如
uv:20260903、device:hll:ios），这类 key 一般 不设 TTL，所以根本不会进入volatile-*类策略的候选池 - 如果用了
allkeys-lru或allkeys-lfu，HLL key 的淘汰概率取决于它最后一次被PFADD或PFCOUNT的时间/频次——但PFADD是写操作，会更新 LRU 时间；PFCOUNT是只读，在 Redis 7+ 中默认 不更新 LRU（除非配置maxmemory-policy allkeys-lru并启用lru-clock采样） - HLL key 体积小（固定 ~12KB），相比一个大
Hash或Sorted Set，淘汰它释放的内存少，调度器在采样时“性价比低”，自然优先挑更大的鱼
真正危险的是误用导致的内存膨胀
比“HLL 被淘汰”更常发生的问题，是把不该用 HLL 的地方硬套上去：
- 用
PFADD往同一个 key 持续灌入本该分片的流量（比如所有用户行为都塞进uv:total），导致单 key 数据量虽仍只有 12KB，但业务上已失去分析维度 - 忘记清理过期的 HLL key（如
uv:20260801在 9 月还留着），大量冷 key 堆积，挤占dict内存，间接推高used_memory_overhead - 误把 HLL 当做 Set 用：试图通过
PFADD+PFCOUNT来判断某个元素是否存在——PFCOUNT不支持单元素查询，也无法反查内容
这些操作不会触发淘汰，但会让内存使用变得不可控、不可预测。
真正要盯住的，不是“HLL 会不会被踢”，而是 “这个 HLL key 是否还在被业务消费” 和 “它的命名是否支持按需 TTL 自动清理”。否则，12KB × 百万个废弃 key，比一个被误淘汰的 HLL 更伤。
