Redis 7.0需手动启用listpack才能降低小结构内存开销20%以上，关键配置为list-max-listpack-size等新参数，旧ziplist参数已弃用且无效。
Redis 7.0 能在不改业务代码的前提下，把小结构内存开销压低 20% 以上——关键不是“升级就自动生效”，而是必须让 listpack 实际接管数据存储，否则仍走旧路径。
确认 listpack 是否真正在用
升级后内存没降，大概率是数据没进 listpack。Redis 不会强制迁移已有数据，只对新写入或重编码的结构生效。
- 用
DEBUG OBJECT key查看实际编码：返回encoding: listpack才算成功；若显示quicklist或linkedlist，说明已退化 - 检查配置项：
list-max-listpack-size（默认 -2）决定何时从listpack升级为quicklist；设为负数（如 -2）会直接跳过listpack，必须调成正整数（如 1024）才启用 -
hash-max-listpack-entries和zset-max-listpack-entries同理，若设得太小（如 64），小 Hash/ZSet 也会被提前升级为hashtable/skiplist，反而增加元数据开销
为什么 ziplist 没被删，但 listpack 必须主动启用
Redis 7.0 保留 ziplist 兼容逻辑，但默认禁用它——因为 ziplist 的连锁更新和碎片问题已被证实不可控。而 listpack 是全新实现，不向后兼容旧编码格式，所以必须靠配置“打开开关”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
list-max-ziplist-size这类老参数在 7.0+ 已被标记为 deprecated，继续设置不会触发ziplist，也不会报错，只是无效 - 真正起作用的是带
listpack字样的新参数，比如list-max-listpack-size、hash-max-listpack-entries - 如果同时设置了新旧两套参数，Redis 优先采用新参数；旧参数完全被忽略
listpack 的内存节省不是线性的，得看数据特征
节省幅度取决于你存的是什么。对整数、短字符串这类小对象，listpack 效果最明显；对长字符串或嵌套结构，优势迅速衰减。
- 存 1000 个 16 字节字符串：
listpack稳定在 ~16.5KB；ziplist因 prevlen 字段 + 对齐填充，浮动在 18–24KB - 存 64 位整数：
listpack仅需 3 字节，ziplist要 5 字节（编码 + 长度字段），省 40% - 但存 10KB JSON 字符串时，两者头部开销占比极小，差异可忽略；此时更应关注是否该用
RedisJSON模块而非原生 String
别忽略 jemalloc 分配器的配合效应
listpack 降低内存碎片，本质是让 jemalloc 更容易复用固定尺寸内存块。但这需要 jemalloc 5.3+ 版本支持 mallctl 接口，且 Redis 编译时未禁用它。
- 用
INFO memory查mem_allocator字段，确认是jemalloc-5.3.x或更高 - 若显示
libc，说明用了系统 malloc，listpack的碎片优化效果会打折扣 -
mem_fragmentation_ratio降到 1.1–1.3 是listpack+ jemalloc 协同生效的典型信号；若仍在 1.6+，优先排查分配器版本和配置项是否匹配
真正容易被忽略的点是：listpack 的收益只在中小规模静态数据上稳定兑现；一旦频繁做 LPOP/RPUSH 混合操作，或元素长度剧烈波动，realloc 次数上升，外部碎片可能反超——这时候得权衡是调大 list-max-listpack-size 延迟升级，还是接受 quicklist 的稳定性。
