List内存飙升的根本原因是小数据量时用ziplist（紧凑连续内存），超阈值后整体切换为linkedlist，64位下每个节点额外占至少48字节；应协同设置list-max-ziplist-entries（512～1024）和list-max-ziplist-value（≤64），并优先通过Hash替代、分片、存ID查表等设计优化内存。
为什么List在大数据量下内存飙升？
根本原因是 Redis 的 List 底层会根据数据规模和元素大小自动切换编码：小 List 用 ziplist（紧凑连续内存），一旦超过阈值就升格为 linkedlist（每个节点带指针+元数据）。64 位系统下，一个 linkedlist 节点至少额外占用 48 字节（prev/next 指针 + malloc 头 + 对齐填充），10 万条简单字符串可能因此多占 4–5 MB——这还没算 key 本身的开销。
list-max-ziplist-entries 和 list-max-ziplist-value 怎么设？
这两个配置决定 ziplist 是否启用，必须协同调整：
-
list-max-ziplist-entries控制元素总数上限，建议设为512～1024；设太高会导致ziplist查找变慢（O(n) 扫描），且单次 realloc 风险增大 -
list-max-ziplist-value控制单个元素最大字节数，建议 ≤64；若存的是数字 ID 或短 token，设成32更稳 - 两者任一超限，整个 List 就退化为
linkedlist，不是“部分退化” - 修改后需重启或
CONFIG REWRITE生效，且只对新建或重写后的 List 生效（已有大 List 不会自动降级）
比调参更有效的三个实操动作
参数只是兜底，真正省内存靠设计：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
Hash替代List存对象：比如用户操作日志，别存成["{id:1,ts:123}", "{id:2,ts:124}"]，改用HSET user:log:12345 1 '{"ts":123}' 2 '{"ts":124}'，字段名用整数、值用紧凑 JSON，内存常能压到 1/3 - 强制分片：单个 List 超过 5k 元素时，按时间戳哈希拆成
log:202607:0～log:202607:7共 8 个，既避免单 key 过载，也利于LTRIM精准裁剪 - 禁用冗余 value：避免在 List 里存完整对象字符串，改存 ID + 外部查表；或用
SETBIT/BITFIELD存状态类数据（如“用户是否签到”），1 亿用户仅需 ~12 MB
容易被忽略的陷阱
很多人试了 ziplist 配置却没效果，常见原因：
- 用
LPUSH往空 List 插入 1000 个长字符串，但第 1 个就超list-max-ziplist-value，整个 List 从一开始就是linkedlist - 用
DEBUG OBJECT key看编码是quicklist（Redis 3.2+ 默认），误以为没生效——其实quicklist是 ziplist 的双向链表封装，仍受那两个参数控制 - 没清理过期数据：List 本身不支持 TTL，得靠外部定时任务 +
LRANGE+LTRIM组合裁剪，否则冷数据永远堆积
真正压内存的关键不在“怎么塞”，而在“要不要塞”和“塞什么”。List 适合队列、近期事件流这类天然有边界的数据，别把它当通用存储桶用。
