MEMORY USAGE 返回的是估算值而非真实内存占用，因其不包含 jemalloc 实际分配块、哈希表空桶及 dict 结构开销；实测 1000 万 MD5 字符串 set 中，它比 used_memory 少约 300 MB。
直接用 MEMORY USAGE 命令就能拿到真实值，但光看这个数字容易误判——它不区分底层编码、不反映哈希表负载因子、也不告诉你 jemalloc 实际分配了多少内存块。
为什么 MEMORY USAGE 返回的值不能直接当“真实占用”用
Redis 的 MEMORY USAGE 返回的是估算值，基于 key 的 redisObject + 底层数据结构的粗略计算，不包含：
- jemalloc 实际分配的内存块（比如你存一个 12 字节字符串，jemalloc 可能分配 16 或 32 字节）
- 哈希表的空桶（
bucket数量是 ≥ 元素数的最小 2^n，1 亿元素可能对应 134,217,728 个 bucket） - dict 结构本身的固定开销（如
dict对象本身占 96 字节，两个哈希表指针各 8 字节）
实测：一个含 1000 万 32 字符 MD5 字符串的 set，MEMORY USAGE 返回约 1.2 GB，而 INFO memory 中 used_memory 增量接近 1.5 GB——差的那 300 MB 就是 jemalloc 和 dict 结构吃掉的。
怎么判断 set 当前用的是 intset 还是 hashtable
运行 DEBUG OBJECT key_name，看返回里的 encoding 字段：
- 返回
encoding:intset→ 所有元素是整数且 ≤set-max-intset-entries（默认 512） - 返回
encoding:hashtable→ 已转为哈希表，这是绝大多数业务场景的真实状态
注意：intset 内存极紧凑（纯整数数组），但一旦插入一个非整数或超限，整个结构会一次性复制迁移成 hashtable，瞬间翻倍内存 —— 这个过程在大 key 上可能触发 OOM。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
估算 1 亿条字符串 set 的内存时必须带入的参数
按 hashtable 编码（即生产环境最常见情况），关键项有：
- 每个元素平均长度（比如 32 字节 MD5 字符串）
- redisObject 开销：16 字节（固定）
- SDS 开销：元素长度 + 9 字节（len + alloc + null terminator），再向上对齐到 jemalloc 的 chunk 边界（如 32→32，33→40→48）
- dictEntry 开销：每个元素对应一个
dictEntry，含 3 个指针（24 字节），jemalloc 分配 32 字节 - 哈希表 bucket 数量：≥ 元素数的最小 2^n（1 亿 → 134,217,728 个 bucket，每个 bucket 是 8 字节指针 → 约 1.02 GB）
粗略公式：total ≈ (16 + SDS_size + 32) × N + 8 × bucket_count。N=1e8、元素长 32 字节时，SDS_size≈48（32+9=41→对齐到 48），结果约 6.8–7.2 GB —— 和实测值吻合（见 2023 年爬虫去重测试）。
线上大 set 必须监控的三个指标
别只盯着 MEMORY USAGE，这三个更关键：
-
redis-cli --bigkeys输出的 set 大小和元素数（确认是否真大） -
INFO memory中的mem_allocator:jemalloc和used_memory_dataset（排除元数据干扰） -
INFO stats中的evicted_keys和expired_keys（如果开始驱逐，说明内存压力已传导到业务）
真正麻烦的不是“占多少”，而是“增长是否不可控”：比如用户标签系统每天新增 500 万，但没清理过期标签，半年后 key 持续膨胀，这时 MEMORY USAGE 只是个快照，背后是数据生命周期管理缺失。
