Elasticsearch 正则查询 regexp 性能差如何改为 wildcard？

单纯将 regexp 查询语法改为 wildcard 查询语法通常只能带来有限的性能提升，真正的优化关键在于避免前缀通配符以及是否使用了专用的 wildcard 字段类型。

先说结论：修改查询语法只是第一步，若字段基数大或包含前缀通配符，性能问题依然存在，建议结合字段类型调整。

• 先定位：使用 Profile API 确认查询耗时是在匹配阶段还是扫描阶段。
• 先做：检查通配符是否出现在字符串开头，确认 Elasticsearch 版本是否支持 wildcard 字段类型。
• 再验证：观察集群 CPU 使用率及查询延迟，确保没有引发全索引扫描。

核心语法对比与配置

以下是 regexp 查询改为 wildcard 查询的基本语法对比，以及推荐的高效字段映射配置。

// 原 regexp 查询
GET /my_index/_search
{
  "query": {
    "regexp": {
      "postcode": "W[0-9].+"
    }
  }
}

// 改为 wildcard 查询
GET /my_index/_search
{
  "query": {
    "wildcard": {
      "postcode": {
        "value": "W?F*HW",
        "case_insensitive": true
      }
    }
  }
}

// 推荐：7.9+ 版本使用 wildcard 字段类型
PUT /my_index
{
  "mappings": {
    "properties": {
      "postcode": {
        "type": "wildcard"
      }
    }
  }
}

性能差异原理

regexp 和 wildcard 查询在底层机制上非常相似，它们都需要扫描倒排索引中的词条列表来寻找匹配项。regexp 查询会将正则表达式编译为确定有限自动机（DFA），如果表达式复杂，开销会很大。wildcard 查询虽然使用简单的 shell 通配符（* 和 ?），但如果模式以通配符开头（如 *foo），Elasticsearch 仍然需要遍历几乎所有词条，导致性能急剧下降。

真正的性能差异往往来自于是否使用了 Elasticsearch 7.9 引入的 wildcard 字段类型，该类型针对此类查询做了底层优化，而非仅仅改变查询 DSL。注意，wildcard 字段类型基于有限状态转录器（FST）实现，对于高基数字段，其磁盘占用可能高于标准的 keyword 类型。

实施步骤与数据迁移

按照以下步骤评估并实施修改，确保不会引入新的风险。

1. 检查查询模式

审查现有的 regexp 语句，确认是否包含前导通配符。如果模式是 .*foo 或 *foo，改为 wildcard 查询也无法解决性能问题。尽量将通配符放在字符串末尾，例如 value*。

2. 确认版本与字段类型

检查集群版本。如果是 7.9 及以上版本，考虑将字段映射类型从 keyword 改为 wildcard。注意，现有索引的 mapping 类型无法直接修改，必须通过重建索引迁移数据。

GET /_cat/nodes?v

3. 数据迁移（Reindex）

创建新索引并指定 wildcard 类型，然后使用 _reindex 迁移数据。

// 1. 创建新索引，定义 wildcard 类型
PUT /my_index_new
{
  "mappings": {
    "properties": {
      "postcode": {
        "type": "wildcard"
      }
    }
  }
}

// 2. 执行数据迁移
POST _reindex
{
  "source": {
    "index": "my_index"
  },
  "dest": {
    "index": "my_index_new"
  }
}

// 3. 切换别名（可选）
POST /_aliases
{
  "actions": [
    { "remove": { "index": "my_index", "alias": "my_index_alias" } },
    { "add": { "index": "my_index_new", "alias": "my_index_alias" } }
  ]
}

4. 设置保护参数

在生产环境中，建议在 elasticsearch.yml 中设置 search.allow_expensive_queries 为 false，防止意外的昂贵查询拖垮集群。

验证方法

修改后不要直接上线，先在测试环境验证。

1. 使用 Profile API

通过 _profile 参数查看查询各阶段的耗时，确认 rewrite 和 match 阶段的开销是否降低。

GET /my_index/_search?profile=true
{
  "query": {
    "wildcard": {
      "postcode": "W?F*HW"
    }
  }
}

2. 监控集群负载

观察 Kibana 或监控系统的 CPU 使用率。如果查询导致某个节点 CPU 飙升，说明仍然存在全扫描风险。

3. 对比响应时间

在相同数据量下，对比修改前后的查询延迟。如果没有明显变化，说明瓶颈不在查询语法，而在数据分布或字段类型。

常见风险与存储开销

• 前导通配符陷阱：无论是 regexp 还是 wildcard，以 * 或 . * 开头的模式都会导致全索引扫描，应严格避免。
• 高基数字段：如果字段中唯一值非常多（如 UUID），任何通配符查询都会消耗大量资源。
• 版本兼容性：wildcard 字段类型仅在 7.9 及以上版本可用，旧版本只能优化查询模式或改用 ngram 分词。
• 大小写敏感：wildcard 查询默认区分大小写，如需忽略大小写需显式设置 case_insensitive 参数（7.10+ 支持）。
• 存储开销：wildcard 字段类型为了优化通配符查询性能，底层结构不同于 keyword，在高基数场景下可能会增加磁盘空间占用，需评估存储成本。

参考文档

• Elasticsearch Documentation: Regexp Query
• Elasticsearch Documentation: Wildcard Query
• Elasticsearch Documentation: Wildcard Field Type

原文链接：https://www.zjcp.cc/ask/10846.html