Redis小Hash自动用ziplist存储，因hash-max-ziplist-entries（默认512）和hash-max-ziplist-value（默认64字节）双条件满足时触发，超限即转不可逆hashtable。
为什么小 Hash 会自动用 ziplist 存储？
Redis 在 hash 对象元素较少、单个字段和值都较短时，会自动选用 ziplist 编码而非更通用的 hashtable。这不是手动开关，而是由两个配置项共同控制的：
- hash-max-ziplist-entries：默认 512，表示最多存多少个 field-value 对
- hash-max-ziplist-value：默认 64，表示每个 field 或 value 的字符串长度不能超过该值（单位：字节）
只要同时满足这两个条件，Redis 就会用 ziplist；一旦任一条件被突破（比如插入第 513 个字段，或存入一个 65 字节的 value），整个 hash 会立刻转为 hashtable 编码，且不可逆（即使后续删到只剩 1 个字段也不会缩回去）。
怎么确认你的 Hash 当前是否用了 ziplist？
直接查编码类型最可靠：
DEBUG OBJECT myhash
如果返回里有 encoding:ziplist，说明正在享受紧凑存储；如果是 encoding:hashtable，那已经“膨胀”了。
也可以批量检查：用 redis-cli --scan --pattern "myhash:*" | xargs -L1 -I{} redis-cli DEBUG OBJECT {} 2>/dev/null | grep -E "(key|encoding)"，快速筛出哪些 key 还在用 ziplist。
- 注意
DEBUG OBJECT是调试命令，生产环境慎用高频调用 -
MEMORY USAGE myhash能看实际字节数，但不告诉你编码方式 - 某些 Redis 版本（如 7.0+）
INFO memory中的used_memory_dataset_perc偏高，可能暗示大量小对象未被压缩
ziplist 不是万能的：什么时候它反而更费内存？
ziplist 本质是连续内存块，靠遍历偏移量查找字段。当字段数多、value 长度差异大、或频繁在中间增删时，它会面临三类问题：
- 每次在中间插入/删除，都要 memcpy 移动后续所有数据，CPU 开销明显上升
- 虽然总字节数少，但因无法复用空闲 slot，反复修改后可能产生内部碎片（尤其 value 长度波动大时）
- 一旦触发转成 hashtable，不仅内存翻倍（指针 + dict 结构开销），还会导致一次性的内存 spike 和阻塞（rehash 是渐进式，但编码切换是同步操作）
典型反例：用 HSET user:1001 name "Alice" status "active" last_login "2025-04-05T12:30:00Z" avatar_url "https://cdn.example.com/u1001.jpg" —— 其中 avatar_url 很容易超 64 字节，整条 hash 就掉出 ziplist。
实操建议：平衡紧凑性与稳定性
不要盲目调大 hash-max-ziplist-value。64 字节对多数业务字段（id、status、type、score）足够；真正需要长字符串的字段（如 url、desc、token），应拆出去单独建 key，或改用 JSON 类型（Redis 7.0+）。
- 用
HLEN+HSTRLEN抽样检查现有 hash 的规模和字段长度分布 - 如果发现大量 hash 卡在 511/512 边界，可考虑略调高
hash-max-ziplist-entries到 1024，但别超过 2048（否则 ziplist 查找变慢） - 避免在同一个 hash 里混存“短字段”和“长字段”，宁可拆成
user:1001:meta和user:1001:profile - 升级到 Redis 7.0+ 后，对结构化小对象可评估
JSON.SET+JSON.FORGET，它在小数据下内存效率接近 ziplist，且支持部分更新
最常被忽略的一点：ziplist 的节省只在「写入即固定」的场景最明显；只要字段生命周期差异大（比如有些字段几小时就过期，有些永久存在），长期来看 hashtable 的内存管理反而更稳。
