Redis Search 怎样按字段聚合结果

Redis Search 要按字段聚合结果，核心写法是 FT.AGGREGATE：先用查询条件选出文档，再用 GROUPBY 指定分组字段，用 REDUCE 计算每组的数量、总和或平均值，最后用 SORTBY 和 LIMIT 控制返回顺序与页码。它适合“按商品分类统计订单数”“按地区汇总访问量”这类场景，不是把 FT.SEARCH 的明细结果简单截短。

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

先确认分组字段和统计字段的边界

假设索引名是 idx:orders，订单文档有 category 标签字段和 amount 数值字段。要按分类统计订单数量，分组字段是 @category，统计的是匹配文档数；要汇总金额，则另外对 @amount 做 SUM。这两个概念不要混成“按 amount 分组”，否则得到的是每个金额值各自一组。

实际建索引时，参与 GROUPBY 的字段必须已被索引并使用适合聚合的字段类型。查询条件可以先缩小范围，例如只统计状态为已支付的订单；过滤条件属于原始文档筛选，分组结果则属于后续管道。本文只讨论聚合分组、排序和分页，不延伸到索引创建或集群分片。

GROUPBY 和 REDUCE 怎样组成分组统计

最小的数量统计可以写成下面这样：

FT.AGGREGATE idx:orders "@status:{paid}"
  GROUPBY 1 @category
    REDUCE COUNT 0 AS order_count

这里的 1 表示后面有一个分组属性，COUNT 不需要输入字段，所以参数数量是 0。返回结果会带有 category 和 order_count 两个字段。命令中的缩进只是为了阅读，Redis CLI 里也可以写成一行。

如果还要统计金额总和和平均值，可以在同一个 GROUPBY 后追加多个 REDUCE：

FT.AGGREGATE idx:orders "@status:{paid}"
  GROUPBY 1 @category
    REDUCE COUNT 0 AS order_count
    REDUCE SUM 1 @amount AS total_amount
    REDUCE AVG 1 @amount AS average_amount
  SORTBY 2 @total_amount DESC
  LIMIT 0 10

SUM 和 AVG 都需要一个输入属性，所以写成 1 @amount。排序时引用的是刚由 REDUCE 生成的别名 @total_amount。若金额字段缺失、类型不适合数值运算，结果就不能按“总金额为零”想当然处理，应先检查索引字段和数据写入约定。

排序、MAX 和 LIMIT 如何配合分页

当目标是“按订单数取前 100 个分类，再读取第 21 到第 40 个分类”时，推荐把排序范围和页码分开表达：

FT.AGGREGATE idx:orders "@status:{paid}"
  GROUPBY 1 @category
    REDUCE COUNT 0 AS order_count
  SORTBY 2 @order_count DESC MAX 100
  LIMIT 20 20

MAX 100 表示排序阶段只关心前 100 个结果，LIMIT 20 20 再从这 100 个结果中跳过前 20 个并返回 20 个。不要把 LIMIT 20 20 理解成“先取第 20 名到第 40 名再排序”；它的偏移和数量作用于管道当前结果。

并列值会带来分页稳定性问题。例如两个分类的 order_count 都是 12，如果只按数量降序，数据变化或内部顺序变化可能让它们在相邻请求中交换位置。可以增加第二个可比较字段作为稳定排序依据，例如分类名：

FT.AGGREGATE idx:orders "@status:{paid}"
  GROUPBY 1 @category
    REDUCE COUNT 0 AS order_count
  SORTBY 4 @order_count DESC @category ASC MAX 100
  LIMIT 20 20

这里的 4 是两个排序属性及其方向占用的参数项数量。稳定排序只解决并列顺序问题，不会冻结跨请求期间正在变化的数据；需要一致快照时，还要在业务层设计统计时间范围或结果缓存。

遇到空结果或分页不对时按三层排查

第一层看查询是否命中文档：暂时把分组和统计去掉，用同样的查询条件做一次 FT.SEARCH idx:orders "@status:{paid}" LIMIT 0 0，确认不是状态标签写法或拼写错误。第二层看字段是否进入聚合管道：文档字段通常要用 @field 引用，经过 APPLY 或 REDUCE 生成的别名也要按管道字段引用；LOAD 应放在分组前，不能在 GROUPBY 或 REDUCE 后补加载字段。

第三层看分页边界：如果 MAX 小于 offset + num，后面的页自然为空；如果没有 SORTBY 就直接分页，返回顺序通常不适合做稳定页码。对大量分组，先用明确的 MAX 缩小排序范围，再决定是否需要更深页；不要仅靠不断增大 offset 解决统计量过大的问题。

GROUPBY 只能按一个字段吗？

不能。语法中的属性数量可以大于 1，例如 GROUPBY 2 @country @category，结果会按国家和分类的组合分组。数量必须与后续列出的属性个数一致。

COUNT 和 SUM 能放在同一个分组里吗？

可以。一个 GROUPBY 后可以追加多个 REDUCE，分别生成不同别名；排序时选择其中一个派生字段即可。

LIMIT 能替代 MAX 吗？

不能完全替代。两者都可能减少返回量，但 MAX 约束排序阶段关注的前 N 个结果，LIMIT 表示从当前管道中按偏移取多少条。要做“前 N 中的第几页”，应按顺序同时使用。

把这类查询记成一条清晰的管道即可：查询条件负责选文档，GROUPBY 负责合并，REDUCE 负责计算，SORTBY 负责顺序，MAX 负责排序范围，LIMIT 负责页码。每一层只承担一个职责，出现结果不对时就能从命中数、字段类型和分页边界逐层定位。