regexp 与 fuzzy 是什么
两者都作用于倒排索引里的词条：regexp 用 Lucene 正则语法匹配词条，fuzzy 按编辑距离容忍拼写偏差。它们不是模糊搜索的通用替代品——正则范围写宽了成本会急剧上升，fuzzy 则容易命中拼写接近但含义无关的词。
基本信息
| regexp 语法 | 支持 . * ? + {} [] | () 等，默认匹配整个词条 |
|---|---|
| fuzzy 参数 | fuzziness（0/1/2/AUTO）、prefix_length、transpositions |
| 资源限制 | regexp 可用 max_determinized_states 限制状态机规模，默认 10000 |
| 大小写 | 正则可用 case_insensitive 放宽匹配 |
| 作用对象 | 词条而非完整字段值，text 字段按分词结果匹配 |
典型使用场景
- 纠错检索：容忍用户输入中一两个字符的拼写错误
- 按编号规则匹配：例如订单号包含特定模式
- 日志检索：按错误码或路径模式定位记录
- 数据质量检查：用正则找出格式不符合规范的取值
- 作为过渡方案：在补建分词方案之前先临时满足需求
常用写法
常用写法
# regexp：Lucene 正则语法，默认匹配整个词条
GET /my-index/_search
{ "query": { "regexp": { "user.id": { "value": "k.*y", "case_insensitive": true } } } }
# 限制正则复杂度，避免个别查询拖垮节点
GET /my-index/_search
{ "query": { "regexp": { "user.id": { "value": "k.*y", "max_determinized_states": 10000 } } } }
# fuzzy：按编辑距离容错，AUTO 按词长自动取 1 或 2
GET /my-index/_search
{ "query": { "fuzzy": { "user.id": { "value": "kimchy", "fuzziness": "AUTO", "prefix_length": 1 } } } }两种查询对照
| 对比项 | regexp | fuzzy |
|---|---|---|
| 匹配方式 | 按正则模式匹配词条 | 按编辑距离匹配词条 |
| 语法体系 | Lucene 正则，不是 PCRE | 参数化，无需写表达式 |
| 主要成本 | 模式越宽状态机越大 | fuzziness 越大候选词越多 |
| 典型用途 | 编号与格式模式匹配 | 拼写纠错 |
fuzzy 匹配的是索引中的词条：对 text 字段按分词后的词条做容错，对 keyword 字段则按整串的编辑距离计算，两类字段的命中结果差别很大。
prefix_length 能固定词首不参与容错，既减少候选词数量也避免开头就错的误匹配；对编号类字段做纠错时，它通常比整体放宽 fuzziness 更有效。