LRANGE大偏移量会阻塞Redis，因其List底层为双向链表或ziplist，需从头遍历n次（n为偏移量）才能定位，时间复杂度O(n)而非O(1)，导致主线程卡死、接口超时；应改用分片Key或Sorted Set优化。
别用 LRANGE key 0 -1 全量读，也别用 DEL 直删百万元素的 List——这两步都会让 Redis 线程卡死几秒到几十秒，业务请求直接超时。
为什么 LRANGE 大偏移量会阻塞
Redis 的 List 底层是双向链表（小数据）或压缩列表（ziplist），LRANGE 查第 10 万条，就得从头遍历 10 万次节点。不是 O(1)，是 O(n)；n 是偏移量，不是总长度。哪怕只读不写，百万级 List 上执行 LRANGE key 999999 999999 也会卡住主线程。
- 常见错误现象：
redis-cli命令 hang 住、应用接口响应时间突增至 5s+、监控显示latency飙升 - 容易被忽略的坑：很多分页工具类把
page=5000&size=20自动转成start=99980，再喂给LRANGE—— 这等于在逼 Redis 做线性扫描 - 性能影响：单次
LRANGE耗时随偏移量线性增长，100 万元素下偏移 50 万，实测常超 800ms（普通 SSD + 4 核实例）
用分片 Key 替代单一大 List
核心是把逻辑上“一个列表”拆成多个物理 Key，每个控制在 1000–5000 元素以内。写入走 RPUSH 到当前活跃分片，读取时先查分片索引再并发 LRANGE。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 分片命名示例：
user:123:msgs:202605（按月）、user:123:msgs:seq:00001（按序号段） - 分片映射存哪？用 Hash：
HSET user:123:msg:shards 202605 "user:123:msgs:202605"，避免每次都要猜 Key - 删除旧数据用
DEL整 Key，比LTRIM key 0 999快得多 ——DEL是 O(1)，LTRIM对百万 List 是 O(n) - 粒度别太细：单用户分片超过 50 个，Key 数暴涨，影响集群 slot 迁移和
KEYS类命令扫描效率
什么情况下该换 Sorted Set
如果你的查询模式天然带顺序（如“最新 20 条”“某时间段消息”“按权重排序”），ZSET 比 List 分片更省事，底层是跳跃表，ZRANGE、ZRANGEBYSCORE 都是 O(log N)。
- 插入示例：
ZADD user:123:timeline 1748392000 "msg_id:abc"（时间戳作 score） - 取最新 20 条：
ZREVRANGE user:123:timeline 0 19，毫秒级返回 - 注意点：
ZADD同member会覆盖 score，若业务要求唯一性，得加前缀（如"msg_id:abc:1748392000"） - 别犯懒：
ZRANGE key 0 -1仍是 O(N)，哪怕比 List 快，也不该全量扫
批量操作必须走 Pipeline
插入或删除百万级 List 元素时，不用 Pipeline 就等于主动制造阻塞。单条 RPUSH 或 DEL 带来的是网络往返 + Redis 单线程串行执行，Pipeline 把命令攒批发，一次 RTT 解决。
- 插入示例（Python）：
pipeline.rpush('list_key', *batch_items)，每 1000–5000 条execute()一次 - 删除大 List：先用
SCAN渐进式遍历 key，再用 Pipeline 批删 —— 别直接DEL，否则过期触发同步删除可能卡住 - 客户端陷阱：Jedis 的
del(String... keys)看似批量，但仍是服务端逐个执行，不等价于 Pipeline
真正难的不是选技术，而是判断“这个列表到底需不需要随机访问”。如果只是队列消费（RPOP/BRPOP），List 本身没问题；一旦出现分页、跳读、范围查，就该立刻切分或换结构——拖得越久，重构成本越高。
