RediSearch FT.AGGREGATE 的 APPLY 怎么计算临时字段

在 RediSearch 的聚合查询里，原始字段往往还不够直接使用：单价和数量需要先相乘，时间戳需要先取日期，多个字段也可能要拼成一个展示值。FT.AGGREGATE 的 APPLY 就是为每条流水线记录计算一个临时属性，计算结果可以继续交给后面的 APPLY、GROUPBY、REDUCE 或 SORTBY。

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

记住一句话：APPLY expression AS name 是逐条记录的派生字段，不是把结果写回 Redis；AS 后的名字才是后续管道引用的属性。

先分清 APPLY 和 GROUPBY 在做什么

APPLY 处理的是“一条记录应该得到什么新属性”。例如原始记录有 @price 和 @quantity，可以计算出当前记录的 @line_total。它是一对一的转换，不会把多条记录合并成一条。

GROUPBY 才负责按一个或多个属性形成组，通常还要配合 REDUCE 对组内记录计数、求和、取最大值或平均值。两者放在同一条聚合流水线中时，APPLY 适合先准备字段，GROUPBY 和 REDUCE 再使用这些字段。

用 APPLY 计算一个最小临时字段

最小写法是把表达式放在引号中，再用 AS 给结果命名。下面假设索引里已经有可参与聚合的数值字段 price 和 quantity：

# 中文注释：每条命中的记录都计算一个临时金额，不会改写原始文档
FT.AGGREGATE products "*" \
  APPLY "@price * @quantity" AS line_total \
  LIMIT 0 20

# 中文注释：后续阶段要引用派生属性时使用 @ 加上 AS 后的名称
FT.AGGREGATE products "*" \
  APPLY "@price * @quantity" AS line_total \
  SORTBY 2 @line_total DESC \
  LIMIT 0 20

这里的 line_total 是输出属性名，后续引用时写成 @line_total。表达式会针对流水线中的每条记录动态计算；它不会创建 Hash 字段，也不会把计算结果持久化到 JSON 文档。

LIMIT 放在示例末尾只是限制返回数量。它不是 APPLY 的一部分，也不会改变临时属性的命名规则。

连续 APPLY 可以把复杂计算拆开

当表达式需要多个中间值时，可以连续使用 APPLY。前一个 AS 命名的属性会留在当前聚合管道里，后一个表达式可以引用它，这比在每个位置重复一长串公式更容易阅读。

# 中文注释：先得到单条记录的金额，再用该临时属性计算含税金额
FT.AGGREGATE products "*" \
  APPLY "@price * @quantity" AS line_total \
  APPLY "@line_total * 1.13" AS gross_total \
  SORTBY 2 @gross_total DESC

# 中文注释：表达式函数也可以把已有属性转换成新的文本属性
FT.AGGREGATE products "*" \
  APPLY "lower(@brand)" AS brand_key \
  APPLY "format('%s:%s', @brand_key, @sku)" AS lookup_key

拆分时要给每个中间字段取有含义的名字，并注意字段类型。数值运算适合数值属性；字符串函数如 lower、upper、strlen 和 format 则应接收文本属性。不要把临时字段名称误认为原始索引字段，它只在当前流水线中存在。

让 APPLY 生成的字段参与 GROUPBY 和 REDUCE

如果派生字段要参与分组或聚合，关键是把 APPLY 放在使用它的阶段之前。比如时间戳原始值不适合作为日报分组键，可以先用 day 计算日期，再按 @day 分组；金额则可以先算出 @revenue，再用 SUM 求组内总额。

# 中文注释：先把每条记录的时间戳映射为日期属性
FT.AGGREGATE visits "*" \
  APPLY "day(@timestamp)" AS day \
  GROUPBY 1 @day \
    REDUCE COUNT 0 AS visit_count \
  SORTBY 2 @day DESC

# 中文注释：先计算单条收入，再按商品类别分组并汇总收入
FT.AGGREGATE orders "*" \
  APPLY "@unit_price * @units" AS revenue \
  GROUPBY 1 @category \
    REDUCE SUM 1 @revenue AS category_revenue \
  SORTBY 2 @category_revenue DESC

这里的计算关系是：APPLY 产生每条记录的字段，GROUPBY 读取该流水线属性形成组，REDUCE 再把组内的属性压缩为一个结果。若把 APPLY 放到使用属性的阶段之后，就不能达到“先派生、后聚合”的目的。

LOAD 决定 APPLY 能不能看到原始字段

APPLY 只能使用当前管道已经可见的属性。需要聚合的属性最好在索引创建时标为 SORTABLE，这样它们可以直接进入聚合管道；如果属性没有自动可用，就用 LOAD 显式加载。

# 中文注释：显式把文档字段加载到聚合流水线，再交给 APPLY
FT.AGGREGATE products "*" \
  LOAD 2 @price @quantity \
  APPLY "@price * @quantity" AS line_total \
  SORTBY 2 @line_total DESC

# 中文注释：只加载需要计算的字段，避免无目的地把整份文档带入流水线
FT.AGGREGATE products "*" \
  LOAD 1 @price \
  APPLY "@price * 1.13" AS gross_price

不要把 LOAD * 当成默认优化方案。官方命令文档提示，加载文档属性会增加聚合处理成本；生产查询应只带入表达式和后续 reducer 真正需要的字段。对于 GEO 等特殊属性，也要按命令文档要求先加载后再调用相应函数。

缺失值、类型和顺序是最容易踩的坑

• 缺失字段：表达式依赖的属性没有值时，结果可能无法按预期参与排序或 reducer。应在索引设计、数据写入和查询结果处理三处统一缺失值策略。
• 字段类型：乘法、除法和平方根等表达式要求数值语义；文本字段应使用 lower、upper、format 等匹配类型的函数。
• 命名顺序：后续 APPLY、GROUPBY、REDUCE 或 SORTBY 引用的是已经在管道中创建的属性，不能提前使用尚未生成的名字。
• 持久化误解：AS line_total 只是聚合结果中的临时属性，不会把值写回原始 Hash 或 JSON。
• 表达式边界：APPLY 适合行级派生和轻量函数组合；复杂业务规则、跨记录状态和需要写入的结果，应移到写入侧或独立处理流程。

APPLY 的使用速查

总结

使用 FT.AGGREGATE 的 APPLY 时，可以按“原始字段是否可见、表达式是否逐条计算、临时字段是否要继续聚合”来判断写法。先用 AS 命名派生属性，再让后续阶段引用它；需要分组时把 GROUPBY 和 REDUCE 放在后面。最后检查 LOAD、字段类型和缺失值策略，就能避免把临时字段误当成持久化数据或把逐条转换误当成跨记录统计。

相关问题

APPLY 会修改 Redis 里的原始字段吗？不会。它只在当前聚合流水线中生成或替换属性，若要持久化必须另行写入。

为什么 GROUPBY 找不到 APPLY 的字段？先检查 APPLY 是否位于 GROUPBY 之前，并确认引用的是 AS 后的名称，例如 @line_total。

所有字段都需要 LOAD 吗？不需要。优先使用已经可用于聚合的属性；只有当前流水线不可见且表达式确实需要时，才显式 LOAD 对应字段。