redis zset在元素数≥128或任一member字节长度≥64时强制升为skiplist编码，内存激增3–5倍；调高zset-max-ziplist-entries（如512）并精简member、score可维持ziplist以大幅降内存。
zset-max-ziplist-entries 设置太小会导致 skiplist 提前升格
Redis 的 zset 在元素少、member 短时会用 ziplist 编码，否则升为 skiplist + dict 组合，内存直接翻倍。默认 zset-max-ziplist-entries 是 128，意味着只要成员数 ≥128，哪怕所有 member 都是 "a"，也会强制切到 skiplist。
常见误判是“我的 zset 才 150 个元素，应该很轻量”，结果 DEBUG OBJECT myzset 返回 encoding: skiplist，实际内存占用可能是同等数据量 ziplist 的 3–5 倍。
- 检查当前编码：
DEBUG OBJECT myzset，关注encoding字段 - 若想维持
ziplist，可临时调高配置（例如设为 512），但注意：一旦升为skiplist，即使删到只剩 1 个元素，也不会自动降回ziplist -
zset-max-ziplist-value同样关键：它限制的是每个 member 字符串的**字节长度**，不是字符数；UTF-8 下中文一个字占 3 字节，"用户_张三_2026"很容易超 64
Member 内容越短，ziplist 节省越明显
压缩列表（ziplist）每个节点只存原始字节+两个长度字段，没有指针开销。一个 "u1001"（6 字节）在 ziplist 中额外开销约 2 字节；而同样内容在 skiplist 中，仅跳表节点指针+字典哈希桶就至少多占 40+ 字节。
真实业务中，member 常含冗余信息：比如 "order:20260526123456789:user_id=1001:status=done" —— 这种字符串既超 zset-max-ziplist-value，又无法被 Redis 共享对象池复用，纯属内存黑洞。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 优先用整数 ID 或短哈希（如
xxh3_64(member)后取低 8 位）替代长业务字符串 - 避免在
member中拼接状态、时间戳等动态字段；这些应存在关联的HASH或独立 key 中 - 如果必须存语义化字符串，统一做前置映射：建
zset:member_id_map（HASH），zset里只存id，查时两级跳转
分片 zset 不等于简单按 hash 拆 key
把一个大 zset 拆成 zset:shard:0、zset:shard:1… 看似合理，但会破坏 ZRANGE、ZREVRANK、ZCOUNT 等全局语义操作——你没法直接取“全局 Top 10”，得拉所有分片再 merge，延迟和复杂度飙升。
真正有效的分片，是让每个分片承担**独立查询域**：比如按用户地区分片 zset:top_goods:cn / zset:top_goods:us，或按时间窗口分片 zset:daily_rank:20260526。这种分片不依赖跨片聚合，天然适配 ziplist 小结构优势。
- 拒绝“为分片而分片”：如果业务强依赖全局排序，分片前先确认能否用
zset-max-ziplist-entries+ 精简member解决 - 若真要跨片聚合，用 Lua 脚本封装
ZUNIONSTORE+ 临时 key，但注意临时 key 的 TTL 和清理逻辑，否则内存泄漏比不分片还快 - 分片键设计别用
hash(member) % N：member 内容变化会导致重分布；改用稳定标识，如user_id % N或预分配的业务分区 ID
别忽略 score 的类型和精度陷阱
很多人只盯着 member 长度，却忘了 score 本身也影响编码选择。Redis 对 score 是 double 存储，但若你传的是整数字符串（如 "100"），Redis 仍会解析为 double 并存 IEEE 754 格式，占 8 字节；而如果 score 总是整数且范围可控（如 0–65535），完全可以用 ZADD myzset 100 "u1001" 直接传数字，避免字符串解析开销。
更隐蔽的问题是精度：用毫秒时间戳当 score（如 1748287586123）会让每个 score 占满 8 字节，且几乎不可能触发任何压缩优化；若业务只要“天级排序”，score 改用 YYYYMMDD 整数（如 20260526），不仅省内存，还提升 zset 内部比较效率。
- score 尽量传数字字面量，而非字符串；Jedis/Lettuce 等客户端默认会 toString()，需显式传
double或long - 避免无意义高精度：score 不是数据库主键，不需要唯一性，重复 score 完全合法，可考虑归一化或截断
- 极端场景下，score 可“借位”：比如把
score = floor(timestamp/3600)*10000 + priority，用整数实现带权重的时间衰减，仍保持ziplist友好
zset，通过调高 zset-max-ziplist-entries 到 512、将 member 从平均 42 字节压到 7 字节、score 改用日粒度整数后，内存降至 210MB —— 但这个收益只在数据写入前生效；已升为 skiplist 的旧 key，只能靠 DUMP + RESTORE 重建，这点很容易被忽略。
