Elasticsearch搜索调优实战指南与性能优化技巧

Elasticsearch 搜索调优系列继续更新，本文是第二篇。重点围绕索引预处理、Mapping 映射设计、避免使用脚本，以及索引段合并等影响搜索性能的关键优化点展开。先直接看图。

这是整个三篇系列中的第二篇，主要面向 Elasticsearch 5.0 及以上版本，提供更实战、更易落地的搜索性能优化思路、调优策略与最佳实践建议。

1.预索引数据

如果想进一步提升索引和查询效率，一个非常实用的方法是在查询发生之前，先把常见的计算模式预处理到索引中。比如所有文档都包含 price 字段，而且大多数查询都需要按照固定区间执行 range 聚合，那么就可以在写入阶段提前完成区间划分，并把结果保存到索引里，后续再用 terms 聚合替代 range 聚合，通常能获得更好的聚合性能。

比如原始文档是这样：

curl -XPUT 'ES_HOST:ES_PORT/index/type/1?pretty' -H 'Content-Type: application/json' -d '{
  "designation": "bowl",
  "price": 13
}'

对应的搜索请求是 range 聚合：

curl -XGET 'ES_HOST:ES_PORT/index/_search?pretty' -H 'Content-Type: application/json' -d '{
  "aggs": {
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "to": 10 },
          { "from": 10, "to": 100 },
          { "from": 100 }
        ]
      }
    }
  }
}'

优化之后，可以在索引阶段新增一个 price_range 字段，并将其映射为 keyword 类型：

curl -XPUT 'ES_HOST:ES_PORT/index?pretty' -H 'Content-Type: application/json' -d '{
  "mappings": {
    "type": {
      "properties": {
        "price_range": { "type": "keyword" }
      }
    }
  }
}'
curl -XPUT 'ES_HOST:ES_PORT/index/type/1?pretty' -H 'Content-Type: application/json' -d '{
  "designation": "bowl",
  "price": 13,
  "price_range": "10-100"
}'

接下来聚合就改用 terms：

curl -XGET 'ES_HOST:ES_PORT/index/_search?pretty' -H 'Content-Type: application/json' -d '{
  "aggs": {
    "price_ranges": {
      "terms": {
        "field": "price_range"
      }
    }
  }
}'

预索引数据的优势非常直接：避免每次搜索时再去动态计算 range 区间，把常用分组结果提前准备好，能够有效提升 Elasticsearch 聚合查询速度与整体搜索性能。

2.映射

数值字段是否一定要映射成数字类型？答案并不是绝对的。像 ISBN、商品 ID、订单编号这类标识符，或者任何用于关联其他数据库记录的数值，本质上更偏向“标识”而不是“计算”，因此映射为 keyword 往往比 integer 或 long 更合理。keyword 类型天然适用于结构化数据，例如 email 地址、主机名、状态码、邮政编码、标签等。

这类字段通常用于精确匹配、过滤查询、排序和聚合分析，例如筛选所有已发布的博客文章。只有在确实需要全文检索的场景下，比如邮件正文、文章内容、商品描述，才更适合使用 text 类型。

下面是一个 keyword 映射的示例：

curl -XPUT 'ES_HOST:ES_PORT/my_index?pretty' -H 'Content-Type: application/json' -d '{
  "mappings": {
    "my_type": {
      "properties": {
        "tags": { "type":"keyword" }
      }
    }
  }
}'

对于从 2.x 版本升级而来的旧索引，需要特别注意：它们并不原生支持 keyword，而是会尝试把 keyword 自动降级为 string。这样的机制虽然有助于兼容新旧映射配置，但对于长期使用的索引，最好还是在升级到 6.x 之前完成重建。降级只是一种过渡方案，不适合作为长期的 Elasticsearch Mapping 设计策略。

3.避免使用脚本

脚本功能虽然灵活，但在搜索调优场景中，原则上应尽量避免使用，因为脚本通常会增加查询开销。如果业务必须依赖脚本，那么优先选择 Painless 和表达式引擎会更稳妥。

Painless

Painless 是 Elasticsearch 默认提供的脚本语言，特点是安全、简洁且易于控制，既支持内联脚本，也支持存储脚本。对于需要在查询、评分或字段计算中使用脚本的场景，Painless 通常是官方推荐的首选方案。具体语法和能力范围，可以参考官方的 Painless 语言规范；如果需要更系统的使用方法，也建议查阅 Elasticsearch 官方脚本文档。

Lucene 表达式语言

Lucene 表达式会将 JavaScript 表达式编译为字节码，专门面向高性能的自定义评分与排序场景。它支持 inline 和默认存储脚本，在执行效率方面表现非常优秀——甚至可能比自定义 Lucene 代码还快，单文档处理成本极低，因此常被视为高性能脚本引擎中的优选方案。

性能：和其他脚本方案相比，表达式语言在性能上的优势非常明显，尤其是在单文档计算速度方面，通常优于大多数脚本引擎。

语法：它支持 JavaScript 语法的一个子集，也就是单一表达式。具体支持哪些操作符和函数，可以参考表达式模块文档。脚本中可访问的变量包括：

• 文档字段，比如 doc['myfield'].value
• 字段相关的方法，如 doc['myfield'].empty
• 传入脚本的参数，比如 mymodifier
• 当前文档得分 _score（仅在 script_score 中有效）

表达式脚本可用于 script_score、script_fields、排序脚本以及数值型聚合脚本等场景，只要正确传入参数即可完成配置。

4.强制合并只读索引

对于只读索引来说，执行强制合并并尽量压缩为单一分段，通常能够带来比较明显的查询性能收益。最典型的应用场景就是基于时间窗口的索引管理：当前时间窗口内的索引仍在持续写入，而历史索引一旦转为只读，就非常适合执行 forcemerge 操作。

强制合并 API 可以通过接口对一个或多个索引执行合并，核心目标是减少每个分片中 Lucene 段的数量。该调用会阻塞直到合并结束；如果 HTTP 连接中断，请求仍会在后台继续执行，而新的合并请求也会被阻塞，直到前一次合并完成。

curl -XPOST 'ES_HOST:ES_PORT/twitter/_forcemerge?pretty'

请求参数：

• max_num_segments：目标合并后的段数量。设置为 1 表示完全合并。默认情况下会先判断是否有必要执行合并，只有需要时才会真正触发。
• only_expunge_deletes：是否仅合并包含删除标记的段。因为文档在 Lucene 中并不会立即物理删除，而是先标记为删除，在后续段合并时才会被真正清理。该参数默认是 false；如果设置为 true，则只处理包含删除标记的段。需要注意的是，它不会覆盖阈值 index.merge.policy.expunge_deletes_allowed。
• flush：强制合并完成后是否执行 flush，默认值为 true。

对只读索引执行合并是一项非常值得养成的优化习惯。它可以显著减少段数量、降低查询开销，并提升 Elasticsearch 历史数据检索性能，尤其适合日志、时间序列和归档数据等典型场景。