想象你是一家大图书馆的馆长，馆里藏书百万、读者如织。过去，读者想找一本书，只能靠你一台一台书柜地翻，或用最笨拙的书名模糊匹配——慢得像在草垛里找针。后来，馆里来了一位雷厉风行的“超级图书管理员”——小R。他上任后做了一件惊天动地的事：把每本书的内容都拆成“关键词标签”，编成一本巨大的“反向目录”。读者问“哪本书讲缓存？”他翻开目录一秒锁定三排书柜。这个“反向目录”，就是倒排索引；这位小R，就是 RediSearch。 Redis 原本是“内存快枪手”，擅长按 key 查 value，却不擅长“按内容搜字段”。RediSearch 作为一个模块，像给 Redis 这位速记员装上了“图书管理员大脑”，让它能建索引、做分词、算相关度，甚至支持聚合统计。本篇文章不会出现吓人的术语堆砌——我会用图书馆的故事，带你拆解 RediSearch 的倒排索引、压缩算法、四种索引类型，以及它在轻量搜索场景中与 Elasticsearch（大型检索系统）的取舍智慧。

岗位关联

对 AI 从业者而言，RediSearch 是“索引思维”的绝佳样本：学会它，你就明白了搜索系统为何快、何时该自研索引、何时该上重型引擎，这是构建实时 AI 应用的底层工程素养。

目录
  1. 可视化演示
  2. 认识 RediSearch
  3. 倒排索引原理
  4. 压缩与分词
  5. 四种索引类型
  6. 实时索引更新
  7. 查询与聚合
  8. 轻量搜索场景
  9. RediSearch vs Elasticsearch
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示RediSearch倒排索引构建（文档→词项→Posting List）、TEXT/NUM/TAG字段差异化索引与RediSearch vs Elasticsearch性能对比，帮助理解Redis搜索模块核心机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.inverted+'

认识 RediSearch

图书馆里原本有一位名叫 Redis 的“速记员”，他记性绝佳，任何一本书放在哪个书柜，只要告诉他编号，他都能瞬间抓取。可是，当读者问“哪本书的正文里提到过‘缓存’”时，速记员傻眼了——他只知道编号，从不看内容。就在这时，RediSearch 出现了。他不是新来的员工，而是戴在速记员身上的“超级头脑”：依旧用 Redis 的记忆力，但多了“读懂内容”的能力。

技术上，RediSearch 是 Redis 的一个官方模块（Module）。就像给浏览器装插件，Redis 从 4.0 起支持动态加载模块，RediSearch 便是其中最著名的搜索模块。它复用了 Redis 的内存存储与数据结构，不需要额外部署独立进程。原生 Redis 只有 GET、SET 这类 KV 操作，对“按字段查询”无能为力；引入 RediSearch 后，FT.SEARCH 命令可以在一瞬间返回“符合条件的所有文档 ID”。

为什么说它“复用 Redis 数据”？因为索引只是目录，书仍然在书架上。RediSearch 的索引可以建立在已有 Redis 哈希键之上，通过 FT.CREATE 指定 ON HASH 与 PREFIX，便能让管理员自动扫描已有 keys 建立索引。数据无需搬迁，书页不用重抄——管理员只是多花心思做了套目录卡。

倒排索引原理

图书馆的目录柜是老式检索系统的灵魂。过去读者查“Redis“这个词，管理员要翻遍每本书的每一页；而小R制作的”反向目录“完全反过来：目录的每一张卡片只写一个词（词项），卡片背面列出所有包含该词的书名（文档ID）。查”Redis”只需翻到 R 打头那张卡，背后密密麻麻列着十几本书——这就是倒排索引（Inverted Index）的雏形。

倒排索引由两个部分组成：词典（Dictionary）和倒排列表（Posting List）。词典是全部词项的集合，好比目录柜上贴的标签索引；倒排列表是每个词项对应的文档 ID 列表，好比卡片背后列出的书名清单。当 FT.SEARCH 收到查询词，管理员先到词典里二分找到词项卡片，再横扫倒排列表，便能拿到全部匹配文档 ID。

RediSearch 在内存中维护这种结构，并使用压缩编码（如增量编码、位图）让倒排列表紧凑。评分与排序则基于词频等统计量，经典公式为 TF-IDF：

这种“卡片目录”思维贯穿整个 RediSearch：任何查询都不是翻书，而是翻卡。翻卡当然比翻书快成千上万倍。

score(t,d)=tf(t,d)×log⁡(Ndf(t))\displaystyle \text{score}(t, d) = \text{tf}(t, d) \times \log \left( \frac{N}{\text{df}(t)} \right)
词频（TF）看单词在文档里出现多频繁，逆文档频率（IDF）看单词在全图书馆多稀有。常出现的词贡献大，烂大街的“的”“了”贡献趋近于零。
  1. 词频 (tf)单词 t 在文档 d 中出现的次数除以文档总词数，衡量“这本书多强调这个词”。
    tf(t,d)=count(t,d)total words in d\displaystyle \text{tf}(t, d) = \frac{\text{count}(t, d)}{\text{total words in } d}
  2. 逆文档频率 (IDF)总文档数 N 除以包含该词的文档数 df(t)，再取对数。df 越大说明词越常见，权重越低。
    idf(t)=log⁡(Ndf(t))\displaystyle \text{idf}(t) = \log \left( \frac{N}{\text{df}(t)} \right)
  3. 乘积合成TF 与 IDF 相乘，使“本册高频 + 全馆稀有”的词获得高排名。
    score=tf⋅idf\displaystyle \text{score} = \text{tf} \cdot \text{idf}

压缩与分词

图书馆做书名卡片时，如果每张卡都写“一本关于……的图书”，那目录柜会被废话撑爆。小R的诀窍是：先把一句话切成词（分词），丢掉“的、了、是”这类没有区分度的停用词，再把相同前缀的文档 ID 用增量编码压缩——比如倒排列表 [3, 7, 8] 不存原值，而是存 [3, 4, 1]（后一项减前一项的差）。差分的数字更小，占用的字节更少，就像记录“第1本书在第3柜、第2本在第3柜往后4格”。

分词是倒排索引的第一道工序。英文按空格和标点切分；中文没有天然空格，RediSearch 使用分词器（Tokenizers）配合词典或模型把句子切成“缓存/架构/实战”这样的词元。分词后的词元先过一层停用词过滤（Stopword List），再经过词干化（Stemming）把“running“归并成”run”。

压缩层面，RediSearch 的倒排列表支持增量编码（Delta Encoding）与变长字节（VarByte）编码，大量相邻文档 ID 的差值很小，可以用一个字节存下。数值索引还使用Roaring Bitmap 位图压缩，把文档 ID 集合按高 16 位分桶，桶内用紧凑的位图表示。“差多少”比“是多少”更省空间，这是所有索引压缩术的共同心法。

分词与压缩，一个负责“提炼有效信息”，一个负责“压缩存储空间”。目录做得又精又薄，查询自然又快又省。

deltai=docIDi−docIDi−1\displaystyle \text{delta}_i = \text{docID}_i - \text{docID}_{i-1}
倒排列表里并不存完整文档 ID，而是存与上一个 ID 的差值。差值常常很小，小数字占位少，目录自然更薄。
  1. 排序文档 ID 按从小到大排列，保证差值非负且尽量小。
    docID1<docID2<⋯<docIDn\text{docID}_1 < \text{docID}_2 < \dots < \text{docID}_n
  2. 求差每个位置存储与前一个 ID 的差值，首项保持不变。
    deltai=docIDi−docIDi−1(i>1)\text{delta}_i = \text{docID}_i - \text{docID}_{i-1} \quad (i > 1)
  3. 还原解码查询时从左到右累加差值，即可还原原始 ID 列表。
    docIDi=docIDi−1+deltai\text{docID}_i = \text{docID}_{i-1} + \text{delta}_i

四种索引类型

图书馆的目录不止一种：书名目录、作者目录、价格区间表、类型标签墙。RediSearch 建索引时也要声明字段类型，不同类型的字段拥有不同的“目录形态”，这就是 TEXT、NUMERIC、TAG、GEO 索引。文本索引好比书名目录，支持全文匹配与模糊搜索；数值索引是一场价格区间排序——书按价格从小到大插在特定书架上，查“50~100 元”只需抽出一段。

标签索引很像图书封底的类型标签：“科技”“文学”“历史”，每个标签精确对应一组书；多选标签时，管理员做集合的并集/交集运算。前缀索引则像姓名索引，用户输入“卡”就能联想“卡夫卡”“卡尔维诺”。在 RediSearch 中，建索引的语法是 FT.CREATE 加 SCHEMA 子句：

逐项拆解：title TEXT 为标题建全文索引；price NUMERIC 为价格建数值索引，支持范围查询；tags TAG 是标签字段，用逗号分隔多个值。GEO 类型则可存经纬度，实现“附近 3 公里”这样的地理检索。

不同索引类型的存在，是因为“精确匹配、范围查询、包含匹配”是三种截然不同的查找逻辑——一套目录无法服务所有提问方式。设计索引时，你要根据未来查询的形态，反推该为哪些字段建立哪些类型的索引。

text1 行
FT.CREATE idx:book ON HASH PREFIX 1 book: SCHEMA title TEXT price NUMERIC tags TAG SEPARATOR ","

实时索引更新

新书源源不断进馆，如果每进一本就把整个目录柜重抄一遍，小R非累垮不可。他的策略是“增量更新”：新书入库时，只把这本书涉及的词项卡片添加文档 ID，旧卡不动。若某本书下架，则在所有相关卡片上划掉它的 ID。这种增量维护让索引始终和书架同步，而无需全量重建。

RediSearch 的索引同步基于 Redis 键空间的 notification 机制：当 HSET 写入一个匹配前缀的 key 时，RediSearch 自动捕获变更事件，把新文档加入倒排索引；DEL 删除时，自动从所有倒排列表中清除对应 ID。整个过程对业务代码透明，你只管写 Redis，索引自行跟进。

如果数据量巨大或初次建索引，RediSearch 还支持后台建造（background indexing）：FT.CREATE 后先返回，索引在后台批量扫描历史数据，新写入的数据则进入增量队列，两者衔接后索引即达一致。删除与失效也很快——倒排列表中的 ID 被标记删除，查询结果过滤即可，物理清理则延迟到合并阶段。

动态更新是所有搜索系统的“生命线”。如果索引是静态快照，那它和书架之间的差距会越来越大。RediSearch 借助 Redis 事件驱动，把“建卡”变成了日常动作，而不是一次性工程。

查询与聚合

读者找书时，小R的答复方式也很讲究：支持“标题含 Redis 且 价格 50 元以下 且 标签是科技”这种组合条件。他的速查手册语法是 @字段:值：@title:redis @price:[0 50] @tags:{科技}，字段与字段之间默认是 AND 关系，| 则表示 OR。这比原生 Redis 一个 key 查一个值强大太多。

深度查询能力还包括过滤（FILTER）、排序（SORTBY）、分页（LIMIT）以及聚合管道。聚合就像一个“月度统计报表”：把书籍按标签分组，统计每组数量、平均价格、最贵书籍。例如：

这个命令把全部书按 tags 分组，统计每组数量，再按数量倒序。聚合结果可以继续做后续处理（如 APPLY 计算百分比），形成一条流水线。查询语法决定了系统的表达力：能查多细、能算多深，全看这一步的设计。

text1 行
FT.AGGREGATE idx:book "*" GROUPBY 1 @tags REDUCE COUNT 0 AS cnt SORTBY 2 @cnt DESC

轻量搜索场景

小R的这套本事，特别适合“社区图书角”这种规模不大、却要实时响应的场景。社区图书角只有几千本书，没必要建一座国家图书馆。RediSearch 正是这样的轻量方案：自动补全（用户输入“redis ca“，下拉框即时提示”redis cache“）、模糊搜索（拼写差一两个字母也能命中）、拼写纠错（输入”redsi“提示”redis”）。

这些能力对应底层命令——自动补齐基于前缀索引与字典树实现；模糊搜索基于编辑距离算法；纠错则是对词典做近似匹配。在 AI 应用中，一个典型的轻量模式是：先查缓存，再查 RediSearch，最后才考虑是否回源数据库。比如电商场景里，商品按“品牌+价格区间+标签”过滤，Redis 承受高并发读，RediSearch 负责条件检索，两者合体扛住每秒上万次查询。

轻量搜索的精髓是“恰到好处”：单机数十 GB 数据、千万级文档、毫秒级延迟，RediSearch 完全胜任。只有当数据量跨入百亿级、需要跨机房分布式检索时，才需要换更大的武器。

RediSearch vs Elasticsearch

国家图书馆和社区图书角用的是完全不同的管理方案。Elasticsearch（ES）是一套完整的分布式搜索引擎，类似国家图书馆的“中央检索系统”：分片、副本、跨节点聚合、复杂分词——功能强大，但需要专人运维、至少三节点起步。RediSearch 则是社区图书角的管理员：单机内存运行、零额外进程、和 Redis 共用基础设施，开箱即用。

扩展性差异是划界线的关键。ES 通过水平分片，索引可以散布到几十台机器；RediSearch 虽然支持集群版，但整体设计更偏向单机高性能。当数据量只有几千万、查询 QPS 是主要矛盾时，RediSearch 的端到端延迟通常更低（因为省去了网络序列化与分布式协调）；当数据量上百亿、需要复杂分词与动态映射时，ES 的生态更成熟。

取舍建议：优先用 RediSearch 解决轻量级搜索与实时过滤——部署简单、无额外运维、与 Redis 缓存同构；当搜集群规模与复杂搜索类型（如全文 + 同义词 + 多语言分析）成为硬性需求，再将 ES 引入，甚至让两者共存：RediSearch 扛实时过滤，ES 做深度分析。选型不是比谁更强，而是比谁更契合你的数据规模和团队运维能力。

AI 应用场景

实时订单检索

阶段：数据服务层 / 在线查询

解决的问题：在电商订单系统中，运营后台需要“按订单号、用户ID、商品名、状态字段组合过滤”实时查询。传统 Redis 只能按订单号单点查询，无法按字段组合扫描；若把所有组合都缓存，内存将爆炸。RediSearch 对订单哈希建索引后，任意字段组合均可毫秒级返回，且与 Redis 缓存同构。

具体案例：某二手交易平台用 FT.CREATE idx:order ON HASH PREFIX 1 order: SCHEMA buyer TAG seller TAG item TEXT price NUMERIC 建立索引，运营后台输入“买家ID + 价格区间 + 商品关键词”一秒出结果，无需额外搭建 Elasticsearch 集群。

商品自动补全

阶段：搜索推荐 / 前端交互

解决的问题：搜索框需要“边输入边提示”的自动补全，要求极高吞吐与极低延迟。RediSearch 的前缀索引支持 FT.SUGADD 自动补全命令，内存常驻、亚毫秒级响应，比去请求外部搜索引擎（ES）成本低一个数量级。

具体案例：某跨境电商 App 在 Redis 中维护热门搜索词库（如“无线耳机”“蓝牙音箱”），用户输入前几个字母，FT.SUGGET 命令立刻返回完整候选词列表，日均调用量上亿次，Redis 实例 CPU 占用依旧平稳。

实时标签过滤

阶段：特征存储 / 在线过滤

解决的问题：推荐系统需要在召回阶段按用户画像标签（年龄、性别、兴趣类目）过滤候选物品。原生 Redis 只能用集合求交，条件一多就难以维护。RediSearch 的 TAG 索引天然支持多标签组合条件，把“过滤逻辑”交给索引层执行。

具体案例：某资讯 App 的内容池有 500 万条带标签文章，推荐服务通过 @category:{tech} @level:{hard} 组合标签查询，在 5 毫秒内完成候选集过滤，回传推荐排序模块，极大降低推荐管线的首屏延迟。

Python 演示

python58 行
# 用 Python 字典模拟 RediSearch 的倒排索引构建与查询from collections import defaultdict DOCS = [    (1, "redis cache architecture"),    (2, "search engine inverted index"),    (3, "redis search module"),    (4, "cache design pattern"),    (5, "elasticsearch vs redis search")] def tokenize(text):    # 简易分词：按空白切分并转小写（演示用）    return [w.lower() for w in text.split()] def build_index(docs):    # 倒排索引：词项 -> 文档ID列表    inv = defaultdict(list)    for doc_id, content in docs:        seen = set()        for word in tokenize(content):            if word not in seen:                inv[word].append(doc_id)                seen.add(word)    return inv def search(inv, query):    # 多词 AND 查询：取词项倒排列表的交集，并按命中词数打分    words = tokenize(query)    if not words:        return []    # 候选集：第一个词的倒排列表    cand = set(inv.get(words[0], []))    for w in words[1:]:        cand &= set(inv.get(w, []))    # 打分：命中查询词的数量（可扩展 tf-idf 逻辑）    result = []    for doc_id in cand:        doc_text = dict(DOCS)[doc_id]        hit = sum(1 for w in words if w in tokenize(doc_text))        result.append((doc_id, hit, doc_text))    result.sort(key=lambda x: (x[1], x[0]), reverse=True)    return result def main():    inv = build_index(DOCS)    print("=== 倒排索引 ===")    for word in sorted(inv):        print(f"{word}: {inv[word]}")    print("\n=== 查询: redis search ===")    for doc_id, score, text in search(inv, "redis search"):        print(f"  文档{doc_id} 得分{score}: {text}")    print("\n=== 查询: cache ===")    for doc_id, score, text in search(inv, "cache"):        print(f"  文档{doc_id} 得分{score}: {text}") if __name__ == "__main__":    main()
目的：用几十行代码演示 RediSearch 最核心的倒排索引思想——文档分词后构建“词项→文档ID”映射，查询时取词项列表交集并排序。
  1. inv = defaultdict(list)声明倒排索引结构，键是词项，值是文档 ID 列表，这正是 RediSearch 词典与倒排列表的雏形。
  2. for word in tokenize(content):对每篇文档分词，是建立索引的第一步。
  3. if word not in seen:同一文档内重复词只记一次，避免倒排列表里出现重复文档 ID。
  4. cand = set(inv.get(words[0], []))取第一个词的倒排列表做候选集合，逐步用后续词交。
  5. cand &= set(inv.get(w, []))集合求交实现 AND 查询，等价于 RediSearch 的多词匹配。
  6. hit = sum(...)用命中词数作为简单打分依据；工业界会用 TF-IDF/BM25 更精细地排序。

常见误区

误区“RediSearch 是不是像 Elasticsearch 一样，要单独装一个服务，然后通过 HTTP 接口访问？”

正解RediSearch 是 Redis 的一个模块，它加载在 Redis 进程内部，并没有独立的服务器进程。你仍然用 Redis 的 RESP 协议（默认端口 6379）发命令，只是新增了 FT.SEARCH、FT.CREATE 等命令。就像给手机装了个相机 App，你还是用同一部手机，只是功能变多了。

为何常见：很多人被“全文搜索引擎”这个概念先入为主，默认它是重型中间件，忽略了 Redis 模块化扩展的轻量设计。

误区“只要我加载了 RediSearch 模块，Redis 里的每个 key 都自动支持全文搜索了。”

正解不是自动的。RediSearch 需要你用 FT.CREATE 显式建索引，并指定 ON HASH、PREFIX 前缀和 SCHEMA 字段类型。没有建索引的 key，FT.SEARCH 是查不到的。建索引就像给书编目录卡，不编卡的书，管理员再厉害也无从查起。

为何常见：Redis 的普通命令开箱即用，让大家惯性认为“加载模块 = 全部数据可搜”，忘了索引是需要设计和创建的。

误区“RediSearch 性能比 Elasticsearch 快，所以我们直接把 ES 换掉就行。”

正解在千万级数据、单机内存可承载的场景下，RediSearch 确实轻量高效；但对百亿级数据、跨机房分布式检索、复杂分词、全文 + 同义词 + 多语言分析等需求，RediSearch 的生态和扩展能力远不及 ES。社区图书角的管理系统再熟练，也替代不了国家图书馆的中央检索集群。

为何常见：看到基准测试中 RediSearch 延迟低、吞吐高，就容易忽略数据规模、高可用、运维复杂度等系统级约束。

误区“Redis 有 `KEYS` 命令能模糊匹配 key，为什么还要用 RediSearch？”

正解KEYS 只能匹配 key 的名字，不能搜索 key 内部字段的文本内容，而且它会全库遍历阻塞 Redis。RediSearch 搜索的是哈希字段里的文本内容并做相关性排序，两者有本质区别。就像“书名目录”只能查书名，而“正文索引”能查书里每一页讲什么。

为何常见：初学者没分清“key 名查找”与“字段内容检索”的边界，造成用错工具。

误区“分词嘛，按空格切一下就行，中文英文差不多。”

正解英文天然以空格分隔，中文没有空格边界，需要基于词典或模型做切分（如“缓存架构”切为“缓存/架构”）。RediSearch 对中文要用专门的分词器，英文则做词干化处理。处理不好中文分词，“缓存架构”会被切成一堆单字，检索效果大打折扣。

为何常见：因为大多数教程示例都是英文文档，让中文使用者误以为分词逻辑完全一致。

面试题

Q1. RediSearch 本质上是什么？

单选题 · easy

  • A.一个独立的搜索引擎进程
  • B.一个 Redis 的模块← 正确答案
  • C.一个 Redis 的持久化文件
  • D.一个替代 Kafka 的消息队列

答案：B。RediSearch 是加载进 Redis 进程的模块，通过 FT.* 命令提供搜索能力，不是独立进程，也不是持久化文件或消息队列。就好比图书管理员佩戴的“检索眼镜”，是他本人的一部分，而不是另一个人。

Q2. 倒排索引中的“倒排”指的是什么？

单选题 · easy

  • A.按文档 ID 倒序排列
  • B.文档到词项的映射
  • C.词项到文档 ID 的映射← 正确答案
  • D.按时间倒序排序

答案：C。正排索引是“文档→词项”，倒排索引反过来，是“词项→文档ID列表”。比如“redis“这张卡片背后列着所有包含它的文档，这就是把”书里有哪些词“倒过来变成”词在哪些书里”。

Q3. RediSearch 建立索引后，数据源来自哪里？

单选题 · easy

  • A.Redis 中的哈希键← 正确答案
  • B.MySQL 的 Binlog
  • C.Elasticsearch 的副本
  • D.本地磁盘的 JSON 文件

答案：A。RediSearch 的索引建立在 Redis 自身的 HASH 键之上，通过 ON HASH PREFIX 指定扫描哪些 key。它的数据源就是 Redis 本库，不需要从外部系统同步数据。

Q4. 下面哪个字段类型适合做“价格区间过滤”？

单选题 · mid

  • A.TEXT
  • B.TAG
  • C.NUMERIC← 正确答案
  • D.GEO

答案：C。NUMERIC 索引会被组织成适合范围查询的结构（如跳表、B 树），专门处理 @price:[50 100] 这种数值区间过滤。TEXT 管全文、TAG 管标签精确匹配、GEO 管经纬度距离。

Q5. TF-IDF 中 IDF 的作用是？

单选题 · mid

  • A.衡量词在单篇文档中的出现频率
  • B.衡量词在整个文档集中的稀有程度← 正确答案
  • C.计算文档的长度
  • D.压缩倒排列表的体积

答案：B。IDF（逆文档频率）= log(N/df)，df 是包含该词的文档数。一个词出现文档越少，IDF 越大，越能区分文档。它类似图书馆里“冷门但精准的关键词”权重更高。

Q6. 关于 RediSearch 的索引更新，正确的是？

单选题 · mid

  • A.每次写入必须手动调用重建命令
  • B.通过 Redis 键空间通知自动增量更新← 正确答案
  • C.只能每天凌晨全量重建一次
  • D.更新索引会阻塞所有查询

答案：B。RediSearch 监听键空间事件，当匹配前缀的 HASH 被写入或删除时自动增量更新索引，业务无感知。这也是它适合实时场景的关键。

Q7. 增量编码压缩倒排列表的存储内容是？

单选题 · hard

  • A.完整文档 ID
  • B.文档 ID 与上一个 ID 的差值← 正确答案
  • C.文档的标题文本
  • D.词项的哈希值

答案：B。倒排列表 [3, 7, 8] 压缩为 [3, 4, 1]，存差值而非原始 ID。差值通常很小，占用更少的字节，查询时累加还原即可。这就像记位置时只记“下一位往前走几格”。

Q8. 以下哪些是 RediSearch 支持的索引类型？

多选题 · mid

  • A.TEXT 文本索引← 正确答案
  • B.NUMERIC 数值索引← 正确答案
  • C.TAG 标签索引← 正确答案
  • D.JSON 全文索引

答案：ABC。RediSearch 支持 TEXT、NUMERIC、TAG、GEO 四类索引字段。它支持 JSON 数据类型，但没有叫“JSON 全文索引”的索引类型，因此 D 项不存在。

Q9. RediSearch 相比 Elasticsearch 的优势有哪些？

多选题 · mid

  • A.部署轻量、无独立进程← 正确答案
  • B.与 Redis 缓存共用基础设施← 正确答案
  • C.百亿级数据分布式扩展
  • D.毫秒级低延迟检索← 正确答案

答案：ABD。RediSearch 的优势是轻量、复用 Redis、低延迟。分布式扩展和百亿级处理恰是 ES 的强项，不是 RediSearch 的优势。选型要扬长避短。

Q10. 关于 FT.CREATE 建索引的 SCHEMA 设计，下列说法正确的是？

多选题 · hard

  • A.TEXT 适合正文关键词匹配← 正确答案
  • B.TAG 适合枚举型精确匹配← 正确答案
  • C.NUMERIC 适合数值范围过滤← 正确答案
  • D.所有字段都必须建 TEXT 索引

答案：ABC。字段类型应与查询形态匹配：关键词全文匹配用 TEXT，精确枚举值用 TAG，范围过滤用 NUMERIC。不是所有字段都需要 TEXT 索引，D 是错误认知——建错索引既浪费内存又可能带来错误查询结果。