LRANGE遍历长List变慢是因为其O(n)时间复杂度，需从头/尾逐节点跳转，大偏移量导致高延迟、CPU飙升；应改用分片Key或Sorted Set优化。
为什么LRANGE遍历长List会越来越慢
Redis List底层是双向链表，LRANGE命令按索引范围取值时，必须从头或尾开始逐节点跳转。当列表长度达到10万+，取中间段（如LRANGE mylist 50000 50099）实际要遍历5万次指针移动——这不是O(1)，而是O(n)且n是起始偏移量。更糟的是，主线程被独占，所有其他命令排队等待。
常见错误现象包括：LRANGE延迟从0.2ms飙升到800ms+、监控里used_cpu_sys持续走高、redis-cli --latency显示毛刺突增。这不是内存不够，是算法复杂度锁死了吞吐。
- 别用
LRANGE key 0 -1全量读取百万级List——哪怕只读不写，也极易触发超时 - 避免在业务逻辑中动态计算大偏移量（如分页参数
page=1000&size=20直接转成start=19980） - 警惕客户端SDK自动封装的“分页工具类”，它们常把
skip硬转为LRANGE偏移
用分段Key替代单一大List的实操要点
核心思路：把一个逻辑列表拆成多个物理Key，每个Key控制在1000–5000元素以内。例如用户消息流，不再存为user:123:msgs，而按时间或ID区间切片：
user:123:msgs:202605（5月全部）user:123:msgs:20260501（5月1日）user:123:msgs:seq:00001（序号00001–00005）
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写入时用
RPUSH追加到当前活跃分片，配合EXPIRE设TTL防堆积 - 读取指定范围时，先查分片映射关系（可用Hash存
user:123:msg:shards），再并发LRANGE多个小Key - 删除旧数据用
DEL整Key，比LTRIM遍历快得多；但注意DEL本身是O(1)，而LTRIM key 0 999对百万列表仍是O(n) - 分片粒度别太细——Key过多会增加Redis键空间压力和集群slot迁移成本
什么情况下该换Sorted Set而不是硬分片
当你需要按时间、分数、权重等自然顺序检索，且查询模式包含“最新N条”“分数区间”“排名前K”时，ZSET比List分片更干净。它底层用跳跃表+压缩列表，ZRANGE、ZRANGEBYSCORE、ZREVRANK都是O(log N)而非O(n)。
例如消息时间线：ZADD user:123:timeline 1748392000 "msg_id:abc"（时间戳作score）ZREVRANGE user:123:timeline 0 19（取最新20条，毫秒级）ZCOUNT user:123:timeline 1748380000 1748392000（统计某时段消息数）
- 注意
ZADD时避免重复member——同member多次插入会覆盖score，若需唯一性，得靠业务层保证或加前缀 - 小ZSET（元素
- 别用
ZRANGE key 0 -1全量扫——虽然比List快，但仍是O(N)，应始终带limit
Sorted Set替代List时最容易忽略的细节
很多人换了ZSET就以为万事大吉，结果发现内存翻倍、写入变慢、排序不准——问题往往出在score设计上。
真实踩坑点：
- 用毫秒时间戳当score，但多实例写入时钟不同步，导致ZRANGEBYSCORE漏数据
- score精度不够（如只用秒级），同一秒内多条消息score相同，ZSET内部按member字典序排，业务语义乱了
- 把业务ID直接当score（如ZADD key 12345 "data"），结果ID是字符串，Redis按ASCII比较，"2">"10"这种反直觉结果频发
- score务必用数值型，推荐
timestamp * 1000000 + microsecond_seq保唯一+保序 - 如果业务只要“最新N条”且不关心精确时间，用自增序列号（
INCR生成）比时间戳更可靠 - 迁移存量List到ZSET时，别用
LRANGE全量读再ZADD——用LRANGE分批（每次1000）+ pipeline，否则网络和内存双爆
