intset 是 Redis 对全整数小集合的内存优化编码，将整数紧凑存储于连续内存，无指针和字符串头开销，比 hashtable 节省3–5倍内存；前提为元素均为合法64位有符号整数且数量不超 set-max-intset-entries（默认512）。
intset 是什么，为什么它能省内存
Redis 的 set 类型在元素全是整数且数量不多时，会自动用 intset 编码替代哈希表（hashtable），这不是你手动选的，是 Redis 自动触发的优化机制。它的核心是把整数紧凑存成一块连续内存，没有指针、没有哈希桶、没有字符串头开销——所以比 hashtable 节省大量空间，尤其当集合只有几百个 int 时，内存可能差出 3–5 倍。
但这个优化有严格前提：所有元素必须是合法的 64 位有符号整数（即能被 strtol 解析且不溢出），且集合大小不能超过 set-max-intset-entries 配置值（默认 512）。
怎么确认你的 set 正在用 intset 编码
别猜，直接查。用 DEBUG OBJECT 或 OBJECT ENCODING 命令看实时编码：
redis-cli> OBJECT ENCODING my_int_set "intset"
如果返回 hashtable，说明已“升级”失败——常见原因包括：
- 插入了一个非整数（比如
"100abc"或"3.14"），哪怕只插一次，整个 set 就永久降级为hashtable - 元素数超过
set-max-intset-entries，且后续再也没删回阈值内（注意：删掉部分元素不会自动切回intset） - 从 RDB/AOF 恢复时，如果当时保存的是
hashtable编码，就不会重新尝试intset
如何让 intset 编码稳定生效
关键不是“怎么开启”，而是“怎么不破坏它”。实操上要守住三条线：
- 写入前确保数据是纯整数：用
isIntegerString()类逻辑校验（比如 Python 用s.lstrip('-').isdigit()不够，得用try: int(s) except），避免前端传参带空格或单位（如"100 ms"） - 控制集合规模：如果业务上集合长期 > 500 个元素，别硬扛，默认值已经偏保守；可调大
set-max-intset-entries，但注意单个intset超过几万整数后，插入/查找性能会明显下降（O(n) 查找） - 避免混入浮点数或大整数：Redis 把
9223372036854775808（2⁶³）当溢出，强制转hashtable；1e5这种科学计数法字符串也会失败
intset 的内存节省到底有多大
以 100 个 int 为例：intset 编码实际占用约 100 × 4 字节（假设用 INTSET_ENC_INT32）+ 一些固定头，总共不到 1KB；而同等内容的 hashtable 编码，至少要建一个初始 4 个桶的哈希表，每个元素存成 robj + sds 字符串，轻松突破 10KB。
但要注意：这个优势只在线性增长阶段明显。一旦集合涨到几千整数，intset 查找变慢，且内存碎片开始显现；此时不如主动用 hashtable，甚至考虑拆成多个小 set 或换用 sorted set + score 做范围过滤。
最常被忽略的一点：intset 不支持过期（EXPIRE），整个 key 级别过期没问题，但没法给集合里某个整数单独设 TTL —— 如果业务依赖细粒度生命周期，就别强求 intset。
