Easysearch：模糊、前缀、通配符查询，什么时候该用，什么时候该禁

一、查询类型总览 #

Easysearch 作为 Elasticsearch 国产化替代方案，兼容其核心查询语法，三种模糊匹配查询的核心差异如下：

二、分类型：适用场景 vs 禁用场景 #

（一）Prefix 前缀查询 #

✅ 适用场景 #

1. 前缀联想匹配：如输入法候选词、商品名称补全（例：输入 “华为” 匹配 “华为手机”“华为平板”）
2. 结构化短字段检索：如用户 ID 前缀筛选（user_id: "U2024*"）、分类编码匹配
3. 高频低延迟需求：Easysearch 2.0.0 版本前缀查询延迟降低 11.4%+，支持高并发场景

❌ 禁用场景 #

1. 中缀 / 后缀匹配需求：如需匹配 “科技”“华为”，前缀查询无法实现
2. 长文本字段检索：文本字段分词后，前缀匹配精度下降（需配合 Edge NGram 优化）

语法示例 #

{
  "query": {
    "prefix": {
      "product_name.keyword": "华为" // 推荐用keyword字段提升性能
    }
  }
}

优化方案 #

• 短字段优先使用 keyword 类型而非 text 类型
• 长文本前缀匹配：配置 Edge NGram 分词（最小 1 字符，最大 10 字符）

"settings": {
  "analysis": {
    "tokenizer": {
      "edge_ngram_tokenizer": {
        "type": "edge_ngram",
        "min_gram": 1,
        "max_gram": 10
      }
    },
    "analyzer": {
      "edge_ngram_analyzer": {
        "tokenizer": "edge_ngram_tokenizer"
      }
    }
  }
}

（二）Wildcard 通配符查询 #

✅ 适用场景 #

1. 复杂模式验证：如邮箱格式（*[@company.com](http://@company.com)）、手机号规则（138?****123）
2. 低频精准匹配：少量数据场景下的中缀 / 后缀匹配（例：查找包含 “migrate” 的配置项）
3. 临时数据探查：非线上环境的一次性数据筛选，无需考虑性能损耗

❌ 禁用场景 #

1. 大数据量 / 高频查询：会触发全索引扫描，Easysearch 集群负载飙升，甚至宕机
2. 高危通配符模式：禁止使用 *abc*（首尾通配）、?* 等模式，枚举成本极高
3. 核心业务链路：线上服务查询延迟要求的场景（Wildcard 查询延迟通常是 Term 查询的 10 倍以上）

语法示例 #

{
  "query": {
    "wildcard": {
      "email.keyword": "user?@example.com" // ?匹配单个字符
    }
  }
}

优化方案 #

• 替代方案：用 NGram 分词 + Match Phrase 查询，性能提升 4 倍以上

// NGram分词配置
"tokenizer": {
  "ngram_tokenizer": {
    "type": "ngram",
    "min_gram": 2,
    "max_gram": 10
  }
}
// 替代wildcard查询
{
  "query": {
    "match_phrase": {
      "content": "migrate"  // 等效于*migrate*，但性能更优
    }
  }
}

• 限制 Term 数量：通过 max_determinized_states 参数控制枚举上限（默认 10000）

（三）Fuzzy 模糊查询 #

✅ 适用场景 #

1. 拼写容错需求：人名（“张三”→“张山”）、品牌名（“Nike”→“Nikee”）、地名等易输错场景
2. 短词匹配：字段长度≤10 字符（如搜索关键词、标签），编辑距离建议设为 1（默认值）
3. 低并发场景：用户自主搜索（如电商搜索框），可接受 100-300ms 延迟

❌ 禁用场景 #

1. 长文本字段：如文章正文、日志内容，会导致计算量暴增（编辑距离算法复杂度随长度上升）
2. 高并发接口：如 API 网关查询、实时数据分析，模糊查询会拖慢整体吞吐量
3. 精确匹配要求：如订单号、身份证号检索，容错会导致误匹配

语法示例 #

{
  "query": {
    "fuzzy": {
      "brand_name": {
        "value": "nikke",
        "fuzziness": 1 // 允许1次编辑（增/删/改字符）
      }
    }
  }
}

优化方案 #

• 控制编辑距离：长词（6-10 字符）设为 1，短词（≤5 字符）设为 0，避免过度容错
• 替代方案：使用拼写检查 API（如 Easysearch 集成的 AI 拼写纠错），先修正再精确查询
• 字段类型优化：仅对 keyword 或短文本 text 字段使用，避免对分词后的长文本字段操作

三、核心禁忌与风险规避 #

四、总结：查询选型决策树 #

1. 需前缀匹配 → 短字段用 Prefix，长字段用 Edge NGram
2. 需拼写容错 → 短词用 Fuzzy（fuzziness=1），长词用拼写检查 + 精确查询
3. 需中缀 / 后缀匹配 → 低频用 Wildcard，高频用 NGram 分词
4. 核心业务 / 高并发 → 优先精确查询，通过分词优化替代模糊匹配