redis sorted set 在元素超128或单member超64字节时自动从listpack切至skiplist+dict，非故障而是设计使然；切换后操作逻辑剧变，且不可逆，易因误判阈值、滥用浮点score或忽视惰性删除导致性能下降。
Redis Sorted Set 在元素量级超过 128 或单 member 超过 64 字节后，会自动从 listpack 切换到 skiplist + dict 结构——这不是性能下降的“故障”，而是设计使然；但若没意识到切换时机和后续行为，反而会踩坑。
为什么 ZSet 突然变慢？先看它什么时候放弃 listpack
Redis 不是“随着数据增长缓慢变慢”，而是在两个硬性阈值被突破时立即切换底层编码，之后所有操作逻辑完全不同：
-
zset-max-listpack-entries默认 128：只要总元素数 > 128，哪怕只多 1 个，就弃用listpack -
zset-max-listpack-value默认 64：任意一个member的字节长度 > 64（注意不是字符数，是strlen()），整个结构立刻升级 - 切换是单向的：即使你删到只剩 10 个元素，它也不会退回到
listpack；内存不会自动收缩 -
listpack下的ZADD是 O(N) 查找 + O(N) 插入（需挪动内存）；skiplist下是 O(log N) 插入，但多了 dict 哈希查重开销
控制 ZSet 大小不能只靠 zremrangebyrank
用 ZREMRANGEBYRANK 截断尾部看似简单，但容易忽略两点：
- 它在
skiplist模式下仍需遍历并标记删除节点，对百万级 ZSet 可能阻塞主线程几十毫秒 - 它不释放内存：被删掉的节点只是逻辑移除，物理内存由惰性回收线程处理，延迟不可控
- 更稳妥的做法是预设容量上限 + 写时截断，例如：
ZADD myzset 100 "user:123" ZCARD myzset # 若返回值 > 1000，则立即执行： ZREMRANGEBYRANK myzset 0 -1001
注意：这里用 0 -1001 表示“保留最后 1000 个”，比 0 999 更安全（避免 rank 计算错位）
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
别盲目调大 zset-max-listpack-* 阈值
把 zset-max-listpack-entries 改成 1000 看似能撑更久，但实际风险更大：
-
listpack是连续内存块，插入中间位置要 memcpy 整段数据，1000 元素时单次ZADD可能达 O(1000) 时间 - Redis 4.0+ 已将
ziplist替换为listpack，后者虽更省内存，但依然不支持并发修改——高写入场景下锁竞争加剧 - 真正需要的是根据访问模式选结构：纯 TOP-K 查询且数据稳定？用
listpack；需高频增删+范围扫描？接受skiplist的 O(log N) 并拥抱它
真正影响性能的常被忽略点：score 类型与共享对象
Redis 对 score 值做了整数对象池优化（0–9999），但如果你用 ZADD myzset 100.0001 "a" 这种带小数的浮点数：
- 每次都会新建
robj，无法复用，内存碎片上升 -
skiplist中比较 score 时浮点精度计算开销略高于整数 - 建议：如业务允许，把 score 缩放为整数（例如时间戳 × 1000），用
ZADD myzset 1716922800000 "task1"而非1716922800.000
压缩限制本身不是瓶颈，误判结构切换边界、滥用浮点 score、以及忽视惰性删除的内存延迟，才是线上 ZSet 慢下来的常见根因。
