调大 hash-max-ziplist-entries 后内存反而上涨，是因为该参数仅为启用 ziplist 的必要条件而非充分条件；一旦任意 field 或 value 超过 hash-max-ziplist-value（默认64字节），Hash 即不可逆地退化为 hashtable，导致内存占用升高。
为什么改了 hash-max-ziplist-entries 内存反而涨了
不是参数调大就一定省内存，hash-max-ziplist-entries 只是启用 ziplist 的**必要条件之一**，不是充分条件。只要任意一个 field 或 value 的字节长度超过 hash-max-ziplist-value（默认 64），整个 Hash 就立刻退化为 hashtable，且不可逆。
- 比如你把
hash-max-ziplist-entries调到 1024，但某个用户资料里存了个 base64 图片 ID（72 字节），那这个 key 永远进不了 ziplist -
HGETALL抽样时别只看字段数，用STRLEN或DEBUG OBJECT key_name看实际 value 字节数——中文、JSON、序列化字符串极易超限 - Redis 7.0+ 已弃用 ziplist，改用 listpack，但配置名和逻辑保持兼容；
OBJECT ENCODING返回的仍是ziplist或hashtable，别被名字误导
怎么确认你的 Hash 实际用了什么编码
别猜，直接查。线上批量检查必须靠命令，不能靠经验。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 单个 key：运行
OBJECT ENCODING myhash，返回ziplist才算成功压缩；返回hashtable就已经“失守” - 批量扫描慎用管道：像
redis-cli --scan --pattern "user:*" | xargs -L 1 -I {} redis-cli OBJECT ENCODING {}容易丢结果、阻塞主线程 - 更稳妥的做法是写 Lua 脚本，在服务端原子执行 SCAN + OBJECT ENCODING，避免网络往返和中间态干扰
- 监控辅助：观察
INFO memory中的used_memory_dataset_perc，如果该值突然下降，往往意味着大量 Hash 正在从 ziplist 升级为 hashtable（因 hashtable 冗余更高）
安全调高 hash-max-ziplist-entries 的实操步骤
调参不是改完就上线，关键在验证是否真正生效、是否带来副作用。
- 先压测：在测试环境同步调高
hash-max-ziplist-entries和hash-max-ziplist-value（比如都设为 1024 和 128），再用MEMORY USAGE key_name对比同一批数据的内存变化 - 动态生效用
CONFIG SET，但禁止在高峰期执行——它会触发全量扫描判断是否重编码，CPU 瞬间拉满 - 推荐组合（中小 Hash 场景）：
hash-max-ziplist-entries 512+hash-max-ziplist-value 128，比默认值（64/64）更实用，又不会因 value 稍长就失效 - 永久生效要写入
redis.conf，但必须等CONFIG SET验证稳定后再落盘，否则重启即回滚
ziplist 真正的代价：CPU 换内存
省下的内存是有代价的：每次 HGET、HSET 都要遍历查找、memcpy、可能触发内存重分配。
- 字段平均数 > 200 且读写频繁时，
used_cpu_sys可能持续升高，instantaneous_ops_per_sec下降 - 对延迟敏感的场景（如实时 tag 统计、秒杀库存校验），宁可多占几 MB 内存，也别强推 ziplist 到极限
- 高频小 Hash（如用户开关配置：10 个字段，值全是
"true"、"123"）最适合 ziplist；混着长 value 的，不如直接接受 hashtable 的稳定 O(1)
