RediSearch 会不会保存结果集？

很多人第一次使用 RediSearch 时，会把它理解成“把查询结果提前存在 Redis 里”。这个理解不完全准确。

先说结论

RediSearch 主要保存的是索引结构，不是每一次查询产生的完整结果集。执行 FT.SEARCH 时，它会根据倒排索引、数值索引、标签索引等结构找到匹配文档，再按照过滤、排序和分页条件返回当前结果。

因此，相同查询通常会重复执行，而不是自动命中一个永久保存的结果集缓存。

索引中保存了什么

假设我们建立如下索引：

FT.CREATE idx:article ON HASH PREFIX 1 article:
  SCHEMA title TEXT tags TAG publishedAt NUMERIC SORTABLE

RediSearch 会为文本词项、标签和数值字段维护适合检索的数据结构。原始数据仍然保存在 Hash 或 JSON 文档中，索引负责回答“哪些文档可能匹配”。

SORTABLE 字段会额外保存适合排序的数据，但这也不等于保存某条查询的最终排序结果。

游标是不是结果集

聚合查询可以使用 WITHCURSOR。游标会在服务端暂时保留查询执行状态，让客户端分批读取后续数据。

它更接近“未读取完的临时查询状态”，而不是长期结果缓存：

• 有空闲超时；
• 会占用服务端资源；
• 读取完成后应该主动删除；
• 不适合作为业务缓存键长期复用。

如果确实需要保存结果

业务上需要复用昂贵查询时，可以显式建立缓存：把查询条件规范化并计算哈希，将文档 ID 列表或聚合结果写入独立 Key，同时设置合理 TTL。

search:cache:{queryHash} -> [doc:12, doc:31, doc:48]

这时要同时考虑数据更新后的失效策略。结果允许短时间不一致，可以使用较短 TTL；要求强一致，就需要在写入业务数据时精确删除相关缓存，而维护成本会明显上升。

实际选择

先直接查询并观察延迟。如果索引设计正确且分页受控，通常不需要缓存结果。只有在聚合昂贵、访问高度重复，并且能够接受明确的一致性策略时，再增加业务缓存。