redis list 的 quicklist 实现对头尾操作（如 lpop、rpush）为 o(1)，但 linsert/lset/lindex 等中间索引操作需先遍历链表再线性扫描 ziplist，长列表下性能断崖式下降；推荐改用 sorted set 或分片 key 优化。
Redis List 在频繁插入删除场景下，只要操作集中在两端（头/尾），默认的 quicklist 实现已经足够高效——LPOP、RPUSH 等命令本身就是 O(1)。真正出问题的，是那些「看似合理却踩中底层结构软肋」的操作。
为什么 LINSERT / LSET / LINDEX 会让性能断崖下跌
这些命令必须定位到中间某个节点，而 quicklist 是“链表套压缩列表”，查找索引时需先遍历链表节点，再在目标 ziplist 内部线性扫描。当列表长度超 10 万，LINDEX mylist 50000 可能触发数万次指针跳转+内存偏移计算，主线程卡顿明显。
- 现象：监控里
used_cpu_sys持续飙升，redis-cli --latency出现 >500ms 毛刺 - 误区：以为“List 支持索引”就等于“随机访问快”，其实只是接口层面的便利
- 替代方案：如果业务真需要按位置增删中间元素，直接换
Sorted Set，用时间戳或序号作score，ZRANGE和ZREM全是 O(log N)
大列表写入时避免 LTRIM 导致的隐式遍历
LPUSH + LTRIM key 0 N 是常见限长写法，但 LTRIM 对百万级列表仍是 O(n)：它要从头开始逐个 unlink 节点，期间阻塞所有其他命令。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 更优做法：用分片 Key 替代单一大 List，例如按小时切片
log:20260713:14，每个分片控制在 2000–5000 元素内 - 写入时只
RPUSH到当前活跃分片，过期用EXPIRE自动清理，删除整片用DEL（O(1)） - 若必须保逻辑连续性，可用 Hash 存分片映射：
HSET log:shards 2026071314 "log:20260713:14"
高频小元素场景下，list-max-ziplist-size 还值得调吗
Redis 3.2+ 的 quicklist 已自动平衡，list-max-ziplist-size 默认 -2（每个 ziplist 最多 8KB），一般无需手动干预。但有两个例外：
- 如果你存的是大量极短字符串（如 UUID 前缀、状态码），可设为正数（如 128），让每个 ziplist 多装些节点，减少链表指针开销
- 若元素平均超 1KB，建议设为负数（如 -1 表示最多 4KB），避免单个 ziplist 过大导致内存拷贝成本上升
- 注意：调整后需观察
INFO memory中mem_clients_normal和mem_clients_slave是否异常增长——那是 ziplist 频繁重分配的信号
最常被忽略的一点：不要在 Lua 脚本里循环调用 LINDEX 或 LSET。哪怕脚本原子，内部仍是逐个 O(n) 查找，100 次调用可能等效于遍历整个列表十遍。该用 LRANGE 一次性取一批，再在客户端处理。
