Redis SORT_RO 怎样只读排序列表中的数值

如果排序只是为了读取一个列表中的数值，通常不需要把结果再写入 Redis。Redis 7.0.0 起提供的 SORT_RO 是 SORT 的只读变体：它可以对 list、set 或 sorted set 做排序并返回数组结果，但不接受 STORE，因此不会创建排序结果键。

官方地址：https://redis.io/docs/latest/commands/sort_ro/

直接使用 SORT_RO key ASC 或 SORT_RO key DESC 读取数值排序结果即可。默认按数值排序；需要外部权重时用 BY，需要分页时用 LIMIT，需要返回关联字段时用 GET。如果要按字典序比较字符串，再显式加上 ALPHA。

为什么会需要 SORT_RO

在排行榜预览、后台列表或只读副本查询中，排序往往只是一次查询动作。传统 SORT 同时支持 STORE，命令表会把它视为可能写入的命令；即使调用者没有使用 STORE，在 Redis Cluster 的只读副本连接上也可能无法按预期路由。

SORT_RO 从 Redis Open Source 7.0.0 开始提供。它保留 SORT 的排序参数，但拒绝 STORE，并可以安全地用于只读副本。这里的“只读”是 Redis 命令对数据键的写入边界，不代表排序没有计算成本：排序仍然需要扫描输入并组织返回结果。

准备数值列表并读取升序结果

先把成员本身设计成可解析的数值字符串。下面的列表故意使用 12、3、25 和 8，这样可以看出数值排序与字符串排序的差别。

# 清理示例键，避免旧数据影响本次读取
redis-cli DEL scores

# 成员本身就是待比较的数值字符串
redis-cli RPUSH scores 12 3 25 8

# 默认按数值升序返回，不把结果保存到新的 Redis 键
redis-cli SORT_RO scores ASC

返回结果应体现数值大小关系：3 在 8 前面，12 在 25 前面。命令只返回数组，不改变 scores 列表的成员顺序，也不会产生一个名为排序结果的新键。

用 DESC 和 LIMIT 控制结果窗口

ASC 是默认方向，DESC 则从大到小返回。需要只读一个结果窗口时，可以组合 LIMIT offset count：先跳过 offset 个排序后的成员，再最多返回 count 个成员。

# 按分数从高到低读取前两项
redis-cli SORT_RO scores DESC LIMIT 0 2

# 跳过最高的一项，再读取后面的两项
redis-cli SORT_RO scores DESC LIMIT 1 2

LIMIT 作用于排序之后的结果，而不是原始列表的下标。比如第二条命令先得到完整的降序关系，再跳过第一项。它只限制返回窗口，不会让输入列表变成有序列表。

用 BY 和 GET 处理外部权重与返回字段

当列表成员是用户编号、商品编号等标识，而真正的排序值存放在其他键中，可以用 BY pattern 指定外部排序依据。模式中的 * 会被每个列表成员替换。排序成员和返回字段是两个不同概念：BY 决定比较什么，GET 决定返回什么。

# 用每个用户对应的权重键作为排序依据
redis-cli SET weight_user-a 12
redis-cli SET weight_user-b 3
redis-cli SET weight_user-c 25
redis-cli RPUSH users user-a user-b user-c

# 按外部权重升序，返回用户编号本身
redis-cli SORT_RO users BY weight_* GET '#'

如果关联对象使用哈希字段，也可以把模式写成类似 profile_*->score 的形式。GET # 表示把排序后的原始元素也返回出来；不写 GET 时，返回的是排序后的元素本身。

# 先按外部权重排序，再同时读取显示名和原始用户编号
redis-cli SORT_RO users BY weight_* GET profile_*->display_name GET '#'

使用多个 GET 时，返回数组会按每个排序成员依次展开对应字段。生产代码应固定字段模式，避免把不存在的关联键误认为有效数据。

识别 SORT_RO 的只读边界

最容易混淆的是 SORT_RO 与 SORT 的关系。两者都能处理 list、set 和 sorted set，也都支持 BY、LIMIT、GET、ASC/DESC 和 ALPHA；区别在于 SORT_RO 不接受 STORE destination。

还要注意复杂度。官方文档给出的复杂度为 O(N+M*log(M))，其中 N 是输入集合元素数，M 是返回元素数；当元素本身已经有序时为 O(N)。因此，LIMIT 可以减少返回窗口，但不应被理解为一定只扫描少量输入数据。

从简单读取到外部权重的采用路径

一个稳妥的使用路径是先保持数据模型简单：成员本身就是可比较的数字时，只使用 SORT_RO key ASC|DESC。当返回结果需要分页，再加入 LIMIT；当成员只是标识符，再引入 BY 与 GET。这样可以把排序依据、结果窗口和返回字段分别观察，避免一次命令混入太多隐含关系。

上线前可以围绕三个指标观察这条路径：输入集合的元素数量 N、每次返回的窗口大小 M，以及关联键缺失时返回结果是否符合业务预期。若业务真的需要持久化一个排序快照，就不应把 SORT_RO 当成替代写入方案；它的价值是只读查询边界，而不是结果缓存。

常见问题

SORT_RO 能排序哪些 Redis 数据类型？

官方文档列出的输入键可以是 list、set 或 sorted set。排序前仍应确认键类型和成员格式与当前比较方式一致。

为什么数字看起来像字符串一样排序？

如果显式使用了 ALPHA，Redis 会按字典序比较；不需要字典序时不要加它。数值列表应保持成员是可解析的数字字符串。

SORT_RO 可以把结果写入另一个键吗？

不能。SORT_RO 拒绝 STORE。如果需求是保存排序结果，应先区分这是一次查询还是一次写入，再选择合适的写入流程。

LIMIT 0 10 是否代表只处理十条数据？

不一定。它表示从排序结果中跳过零项并最多返回十项；排序本身仍可能涉及整个输入集合，复杂度需要结合 N 和 M 判断。

小结

SORT_RO 解决的是“只读取排序结果”这个边界问题：默认可按数值排序，DESC 改变方向，LIMIT 截取窗口，BY 指定外部权重，GET 取回关联字段，ALPHA 切换到字典序。记住它不接受 STORE，就能把只读查询和结果持久化清楚地区分开。