Redis Set在元素全为整数且数量≤512时自动采用intset编码，以节省3–5倍内存；其通过连续内存存储、变长编码和有序二分查找实现高效紧凑，且一旦降级为hashtable则不可逆。
Redis 的 Set 在元素全是整数且数量 ≤ 512（默认）时，自动用 intset 编码，不是为了“更酷”，而是实打实省 3–5 倍内存——关键在于它把整数塞进一块连续内存，不存指针、不建哈希桶、不带字符串头。
怎么确认你的 Set 正在走 intset 路线
别靠猜，直接查实时编码：
OBJECT ENCODING my_set 返回 "intset" 才算成功；返回 "hashtable" 就说明已降级，且不可逆。
- 常见误操作：插入一次
"100abc"或"3.14"，整个 set 永久切到hashtable，哪怕后续全删光再重加合法整数也回不去 - 从 RDB/AOF 恢复时，Redis 不会重新评估是否能切回
intset，只按落盘时的编码加载 -
DEBUG OBJECT my_set可看更详细信息，但生产环境慎用（阻塞主线程）
intset 真正省内存的三个底层原因
它不是“压缩”，而是从数据结构设计上砍掉冗余：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 无指针：
hashtable每个节点要存 key 指针 + next 指针 + 字符串头（至少 16–32 字节），intset是纯int8_t contents[]数组，元素紧挨着 - 变长编码：
encoding字段动态选INTSET_ENC_INT16/INTSET_ENC_INT32/INTSET_ENC_INT64，比如全存0–65535就只用 2 字节/元素，不浪费 - 有序存储：升序排列，支持二分查找（
O(log n)），省掉哈希计算和链表遍历开销，小集合下比哈希表还快
什么情况下 intset 会失效并永久切换成 hashtable
两个条件必须同时满足才启用 intset，破一个就降级，且不回退：
- 元素含非整数：哪怕只插一个
"1"（字符串）或"-123x"（解析失败），intset立即升级为hashtable - 元素超阈值：
set-max-intset-entries默认 512，第 513 个整数插入时触发切换；之后删到只剩 10 个，也不会自动切回来 - 注意：负数合法（如
-99），但超出int64_t范围（±9223372036854775807）也不行，strtol解析会溢出失败
想压测或调试 intset 行为，绕不开的配置和命令
生产环境一般不动，但排查内存异常时得知道怎么调：
- 改阈值：
CONFIG SET set-max-intset-entries 1000（重启失效，仅运行时生效） - 验证是否生效：先
SADD test 1 2 3，再OBJECT ENCODING test；然后SADD test 1000000000000（确保没超 int64），观察是否仍为intset - 注意：频繁插入跨位宽整数（比如先加
32767再加32768）会触发intset全量升级（如从 16 位→32 位），有短暂 CPU 小峰值，但只发生一次
最容易被忽略的是“不可逆性”：intset 降级到 hashtable 后，哪怕你重建一个全新 key 并严格只塞合法整数，只要数量 ≤512，它确实会再次用 intset——但旧 key 永远卡在 hashtable，不会因为删空而复活。内存优化这事，得从第一次写入就守规矩。
