LRANGE 查中间元素会卡住 Redis 主线程，因其底层 quicklist 需 O(N) 遍历，10 万数据跳 5 万节点将阻塞单线程；应改用 Hash+计数器或 ZSET 实现 O(1)/O(log N) 随机访问。
为什么 LRANGE 查中间元素会卡住 Redis 主线程
因为 Redis 的 List 底层是双向链表（quicklist，由压缩列表 ziplist 或双向链表 linkedlist 组成），LRANGE 查中间元素必须从头或尾逐个遍历节点。当 List 有 10 万条数据，你要 LRANGE mylist 49999 49999，Redis 就得跳过前 5 万个节点——这不是 O(1)，而是 O(N) 时间复杂度，且全程阻塞单线程主线程。
常见错误现象包括：
- 监控发现
latest_fork_usec突增（大 List 导致 fork 子进程慢） -
SLOWLOG GET 10里频繁出现耗时 >100ms 的LRANGE记录 - 客户端报
1001（超时错误），但 CPU 使用率并不高——其实是被阻塞在链表遍历上
用 Hash + 数字键替代大 List 的实操方式
如果业务本质是“按序号查某条记录”，比如订单列表、消息流，List 不是唯一选择；用 Hash 拆成 order:1、order:2 这样的结构，再配合一个计数器 order:count，就能把随机查变成 O(1)。
示例操作：
INCR order:count HSET order:1001 user_id 123 status "paid" amount 299.00 HGETALL order:1001
注意点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不要用
HGETALL扫整个 Hash，只查你需要的 key - 若需范围查询（如查第 100–110 条），可额外维护一个
ZSET存序号和时间戳，用ZRANGEBYSCORE替代 - 删除旧数据时，用
HDEL+DEL清理元数据，避免残留
什么时候还该坚持用 List，但必须加约束
只有当你的使用模式严格符合“头/尾追加 + 头/尾弹出”（如任务队列、最新 N 条日志），才适合用 List。此时务必控制长度：
- 写入前用
LLEN检查，超阈值（如 5000）就LTRIM截断 - 禁用
LRANGE ... -1这类不带终点的调用，防止意外拉全量 - 集群环境下，避免对大 List 执行
LINSERT或LREM—— 它们同样 O(N)，且可能触发跨 slot 重定向
用 ZSET 实现带权重的有序随机访问
如果你需要“按时间倒序查第 N 条”，又希望支持分页、跳转、去重，ZSET 是更稳的选择。score 用时间戳（或自增序列），member 存实际数据 ID：
ZADD feed:timeline 1725542340 "post:8821" ZRANGE feed:timeline -10 -1 WITHSCORES
优势明显：
-
ZRANGE支持索引偏移，底层是跳表（skiplist），O(log N) - 天然支持按 score 范围筛选，不用手动维护序号
- 可结合
ZREMRANGEBYRANK自动淘汰老数据，比 List 的LRANGE+LTRIM更精准
真正容易被忽略的是：List 的“顺序”是隐式位置，而 ZSET 的“顺序”是显式 score。一旦你开始依赖“第几条”这个语义，就该把顺序逻辑从存储层移到应用层或 score 上——否则每次查中间，都是在拿生产环境赌运气。
