SORT命令触发高CPU和内存占用，因其需在主线程同步遍历全量数据、执行O(n log n)排序、构建临时结果集；带BY/GET参数时更引发多次随机查找，放大开销。
为什么 SORT 命令会触发高 CPU 和内存占用
SORT 是 Redis 中少数几个真正「遍历+计算」的命令之一。它不是简单查键，而是要：读取整个 list/set/zset → 按规则排序（默认字典序或按外部 key）→ 构建新结果集 → 返回。这个过程完全在主线程中同步执行，且无法中断。
常见高开销场景包括：
- 对一个含 10 万元素的
list执行SORT mylist：Redis 必须一次性加载全部元素到内存，做 O(n log n) 排序，中间结果也占内存 - 带
BY参数，比如SORT user_ids BY user_*->score：每取一个 ID，都要额外执行一次HGET，变成 n 次随机 key 查找 + n 次比较，CPU 和网络延迟（如果是集群代理）双双放大 - 带
GET多字段，如GET user_*->name GET user_*->email：实际是 n × 字段数 次哈希查找，内存临时结构膨胀明显
SORT 和 ZRANGE/SCAN 的本质区别在哪
ZRANGE 能高效返回有序集合某一段，是因为底层跳表（skiplist）已天然有序；SCAN 是渐进式遍历，每次只处理少量 key，不阻塞也不全量加载。而 SORT 没有预建索引，必须现场构建——它本质上是个「运行时排序引擎」，不是「查询接口」。
对比示例：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
SORT users BY score DESC LIMIT 0 10 # 全量读、全量排、再截断
ZRANGE users_sorted 0 9 WITHSCORES # 直接跳表偏移，O(log n) 定位
如果你的数据天然需要排序，优先用 zset 存储，而不是存 list 再靠 SORT 补救。
哪些配置或行为会让 SORT 更危险
以下情况会让 SORT 的代价指数级上升：
- 没设
LIMIT：哪怕只要前 10 条，Redis 仍会完整排序全部数据 - 用
ALPHA对数字字符串排序（如"10","2"）：字典序导致结果错乱，还白耗 CPU - 在
slave节点上执行（尤其开启read-only）：主从复制本身不阻塞，但SORT仍会吃光从节点 CPU，影响同步延迟 - 搭配
STORE写回新 key：不仅算得累，还要序列化写入，可能触发内存碎片或淘汰
替代方案不是“换个命令”，而是重构数据访问路径
别想着把 SORT users BY created_at DESC 改成 SCAN 就行——SCAN 不排序。真实可行的替代是：
- 写入时就按时间戳组织：用
ZADD timeline [timestamp] user_id，查最新 10 个直接ZREVRANGE timeline 0 9 - 分页需求强烈？加一层轻量缓存：用 Lua 脚本预计算并
SET一个带 TTL 的sorted_users_page_1，过期后异步刷新 - 真要动态多条件排序？考虑把排序逻辑下沉到应用层：用
LRANGE或SSCAN分批拉数据，在客户端/服务端聚合排序（注意控制单次拉取量）
最常被忽略的一点：SORT 的性能问题往往不是命令本身的问题，而是 schema 设计阶段没把「排序需求」当成一级约束来建模。等线上跑出慢日志再改，通常已卡在业务耦合深处了。
