ES 系列 #05：ES 查询最佳实践

从字段类型选择、查询语法优化、翻页策略、结果集控制四个维度梳理 ES 查询性能最佳实践，并给出各类型查询的性能基准数据。

ES 系列：ES 简介 · ES 的查询过程分析 · ES 高风险查询识别与规避 · ES 集群与分片配置最佳实践

章节	说明
查询耗时拆解	了解耗时在哪里，才能有针对性优化
字段类型对查询的影响	keyword vs 数值，term vs range
查询语法优化	filter cache、避免危险查询
翻页策略	from+size、scroll、search_after
结果集控制	控制返回字段、控制 size
聚合查询优化	嵌套深度、terms size 控制
机器与集群配置	内存、CPU、预热缓存
查询性能基准参考	Term/Match/聚合 QPS 参考值

查询耗时拆解

一次 ES 查询的主要耗时分布： query then fetch

结论：ES 查询的主要耗时在数据节点。优化方向是减少数据节点需要遍历的数据量和计算量。

字段类型对查询的影响

keyword vs 数值类型的 term 查询

类型	term 查询性能	range 查询性能	适用场景
`keyword`	✅ 最优（倒排索引）	❌ 不适合	精确匹配、枚举值、ID
`long / integer`	❌ 性能差（BKD 树不适合精确查找）	✅ 最优（BKD 树）	范围查询、排序、聚合

⚠️ 数字类型做 term 查询性能非常差。ES 5.x 起相比 2.x 下降约 80%，CPU 利用率飙升 30%+。不需要范围查询时，一律用 keyword。

// 错误：数字类型做 term 查询
{ "term": { "userId": 12345 }}

// 正确：精确匹配用 keyword 类型存储
{ "term": { "userId": "12345" }}

整值型 vs 范围型字段

整值型（double、long、integer、short、byte）
  → 底层 BKD 树，适合 range 查询

范围型（float_range、long_range、date_range、double_range）
  → 存储一个区间，用于"文档区间是否包含查询值"场景

查询语法优化

优先使用 filter（利用 Query Cache）

// 推荐：bool-filter，结果会被缓存
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "status": "active" }},
        { "range": { "price": { "lte": 100 }}}
      ],
      "must": [
        { "match": { "title": "手机" }}
      ]
    }
  }
}

filter 子句的结果会缓存在 Query Cache，相同查询第二次极快
must 参与评分（计算相关度），不被缓存
能用 filter 的条件就不要放在 must 里

避免模糊查询或严格限制

查询类型	危险程度	替代方案
`wildcard`（前后通配 `词`）	🔴 极危险	改用 `match` 分词查询
`regexp`（正则）	🔴 极危险	提前计算好存入字段
`fuzzy`	🟡 较危险	控制 fuzziness 参数
`prefix`	🟡 注意	词长不超过 32 字符

模糊查询的危险原因：wildcard、regexp、fuzzy 内部都需要构建有穷自动机（DFA），词越长、状态数越多，CPU 直接被打满，集群不可用。

// ❌ 危险：前后通配
{ "wildcard": { "name": { "value": "*手机*" }}}

// ✅ 安全：分词查询（性能好 1 倍以上）
{ "match": { "name": "手机" }}

// ✅ 也可以用 wildcard 字段类型（ES 7.9+），性能更好

避免深度嵌套查询

// ❌ 避免：nested 查询
{
  "query": {
    "nested": {
      "path": "comments",
      "query": { "term": { "comments.author": "alice" }}
    }
  }
}

nested 慢 10 倍以上，parent-child 慢 100 倍以上
尽量在写入时把数据打平，join 逻辑放到应用层

避免 script 查询

// ❌ 避免：查询时用脚本计算
{
  "query": {
    "script": {
      "script": "doc['price'].value * 0.9 > 50"
    }
  }
}

// ✅ 提前计算好存入 ES
{ "range": { "discount_price": { "gt": 50 }}}

不要用 match_all 无条件查询

// ❌ 极度危险：全量扫描
{ "query": { "match_all": {} }, "sort": [{ "createTime": "desc" }]}

翻页策略

方案	适用场景	上限	特点
`from + size`	用户翻页（前 N 页）	10000	简单，但深翻页时内存消耗大
`scroll`	批量导出/遍历全量数据	无上限	有状态，不适合实时查询
`search_after`	实时翻页（无随机跳页需求）	无上限	无状态，高效，推荐

from + size 的问题

from=9000, size=100 → 每个分片返回 9100 条 → 协调节点汇总后取 100 条
分片数越多，内存开销越大，是引发 Full GC 的常见原因

规则：from + size 不得超过 10000，size 单次不超过 1000。

search_after 示例

// 第一页
{
  "size": 20,
  "query": { "match_all": {} },
  "sort": [{ "createTime": "desc" }, { "_id": "asc" }]
}

// 后续页：传入上一页最后一条的 sort 值
{
  "size": 20,
  "query": { "match_all": {} },
  "sort": [{ "createTime": "desc" }, { "_id": "asc" }],
  "search_after": [1704067200000, "doc_id_xyz"]
}

结果集控制

只返回需要的字段

{
  "_source": {
    "includes": ["id", "name", "price"],
    "excludes": ["*.description", "raw_content"]
  },
  "query": { "term": { "status": "active" }}
}

减少网络传输量和反序列化开销
对 IO 密集型查询效果显著

控制 terms/should 参数规模

// ❌ terms 参数过多
{ "terms": { "skuId": [1001, 1002, ..., 10000] }}

terms 查询的入参 不超过 100 个（推荐），上限 1024 个（超过将被拦截）
should 子查询数量 不超过 1024 个

别名查询定期清理

别名绑定的索引数量 不超过 20 个
定期解绑历史索引，否则查询会遍历过多分片

聚合查询优化

嵌套深度控制

// ❌ 危险：三层以上嵌套聚合
{
  "aggs": {
    "by_date": {
      "terms": { "field": "date" },
      "aggs": {
        "by_supplier": {
          "terms": { "field": "supplierId" },
          "aggs": {
            "by_sku": {
              "terms": { "field": "skuId" },
              "aggs": { ... }  // 第四层，危险！
            }
          }
        }
      }
    }
  }
}

聚合嵌套 不超过 3 层，深度越深 CPU 和 IO 消耗越大
terms 聚合的 size 不超过 65536，shard_size 同样限制

预计算优化

对 text 字段做聚合时，设置 fielddata: true（会加载到内存，谨慎使用）
优先用 keyword 字段做聚合，避免 fielddata

合理利用 index sorting

// 索引创建时配置排序，对按该字段排序的查询有显著加速
PUT /my_index
{
  "settings": {
    "index.sort.field": "createTime",
    "index.sort.order": "desc"
  }
}

机器与集群配置

JVM Heap 配置原则

JVM Heap 设置为机器内存的 50%，剩余 50% 留给操作系统文件系统缓存（Lucene 依赖 OS Cache）
Heap 不超过 32 GB（超过 32 GB JVM 指针压缩失效，反而更慢）
数据节点内存建议 16G 以上

机器内存 64G → JVM Heap 32G → OS Cache 32G

预热文件系统缓存

# elasticsearch.yml 或 index settings
index.store.preload: ["nvd", "dvd"]

nvd：norms（相关度评分数据）
dvd：doc values（列式存储，聚合/排序需要）
服务重启后预先将段文件加载到 OS Cache，减少冷启动时的查询抖动

分片均衡

确保每个数据节点都分配了某个索引的分片（查询并发遍历各节点）
设置单节点最大分片数，避免分片不均：

PUT /my_index/_settings
{
  "index.routing.allocation.total_shards_per_node": 2
}

冷热数据隔离

历史数据（访问热度低）迁移到冷集群或 SATA 机器
高频访问数据保留在 SSD 集群

查询性能基准参考

以下为索引 50 GB、文档数 2 亿+、字段数 8 个的简单查询压测值，单个数据节点。

机器类型	配置	Term QPS	Term avg(ms)	Match QPS	Match avg(ms)
SSD（8C 16G）	VM/物理机	~1000	12-16	~1000	11-13
高性能 SSD（16C 32G）	-	~1000	15	~2000	12

聚合查询（Bucket Agg / Matrix Agg）：

机器类型	Bucket Agg QPS	Matrix Agg QPS
SSD（8C 16G）	~1000	~1500
高性能 SSD（16C 32G）	~1500	~2000

结论：

查询性能 VM/物理 SSD 相当，高性能 SSD 优势主要在 Match 和聚合查询
查询性能对 I/O 更敏感，高读写业务需要 SSD 机器
聚合查询对 I/O 要求更高于普通查询

参考资料

Elasticsearch - Tune for search speed

Elasticsearch - Paginate search results

Elasticsearch - Query and filter context

ES 系列 #05：ES 查询最佳实践

目录

查询耗时拆解

字段类型对查询的影响

keyword vs 数值类型的 term 查询

整值型 vs 范围型字段

查询语法优化

优先使用 filter（利用 Query Cache）

避免模糊查询或严格限制

避免深度嵌套查询

避免 script 查询

不要用 match_all 无条件查询

翻页策略

from + size 的问题

search_after 示例

结果集控制

只返回需要的字段

控制 terms/should 参数规模

别名查询定期清理

聚合查询优化

嵌套深度控制

预计算优化

合理利用 index sorting

机器与集群配置

JVM Heap 配置原则

预热文件系统缓存

分片均衡

冷热数据隔离

查询性能基准参考

评论 (0)

发表评论