redis不提供自动数据压缩，但通过优化hash的ziplist/listpack编码可显著降内存——需合理配置hash-max-ziplist-entries和hash-max-ziplist-value，并用object encoding与hlen命令验证编码状态，避免因单个超长value导致整条hash退化为hashtable。
Redis 本身不提供自动数据压缩功能，但通过合理配置编码方式（尤其是 Hash 类型的 ziplist / listpack 优化），能显著减少内存占用——这不是“压缩数据”，而是避免冗余结构开销，让小对象以紧凑格式存储。
让 Hash 尽量走 ziplist 编码
Hash 是最常被误用也最易优化的数据类型。Redis 在满足条件时会把 Hash 存成 ziplist（Redis 7.0+ 改为 listpack），它是一段连续内存，没有指针、哈希表桶等额外开销，比 hashtable 节省 60% 以上内存。
- 关键配置项有两个：hash-max-ziplist-entries（字段数上限）和 hash-max-ziplist-value（单个 value 最大字节数）
- 默认值是 512 和 64，但业务中邮箱、手机号、短描述常超 64 字节，一超标整条 Hash 就不可逆升级为 hashtable，内存可能翻倍
- 实测建议：若字段稳定在 8–12 个（如用户基本信息），hash-max-ziplist-entries 可设为 1024；若多数 value 是状态码、ID、布尔值（如 "active"、"1"），hash-max-ziplist-value 可提至 128
- 切忌设成 1024 去硬塞长文本——查找变慢、重分配易卡顿，且新版 listpack 对大 value 仍会退化
快速确认你的 Hash 是否还在用紧凑编码
别靠猜测，用两个命令交叉验证：
-
redis-cli object encoding user:1001 —— 返回
ziplist或listpack才算成功；返回hashtable就已退化 -
redis-cli hlen user:1001 —— 看字段数是否低于你设的
hash-max-ziplist-entries - 再挑几个字段查长度：redis-cli hstrlen user:1001 email，找出第一个超
hash-max-ziplist-value的 value
避开 ziplist 退化的典型陷阱
很多内存暴增不是因为数据变多，而是某次写入悄悄触发了编码降级：
- value 含 base64 图片片段（约 200 字节）？必须关掉 ziplist：
hash-max-ziplist-value 0，否则强制退化 - 用 HSET 写入一个长字段（如 "alice_long_name_2026@example.com" 共 72 字节），整条 Hash 立刻从 ziplist 升级为 hashtable
- HGETALL 操作在 hashtable 上仍是 O(1)，但内存开销剧增——指针、桶数组、链表节点全要空间
配合其他轻量级优化手段
单靠 ziplist 配置不够，需组合使用：
- 键名尽量短：user:profile:12345 → u:p:12345，省下的不只是字节，还有 dict 哈希桶索引开销
- 优先存整数：SET age 30 比 SET age "30" 更省内存（复用共享对象池，省去 SDS 结构）
- 避免单值用 String：1 亿个 partnerId→objectId 映射，改用 Hash 分片（如 hset objmap:001 p123 o456）可降低整体内存 40%+
