查询优化

发表于 2022-07-27 更新于 2025-08-13 分类于 Elasticsearch Waline：阅读次数：本文字数： 3.7k 阅读时长 ≈ 3 分钟

Elasticsearch 6.x 查询优化：提升检索效率的核心策略

Elasticsearch 的查询性能直接影响业务响应速度，尤其在大规模数据场景下，优化查询链路、减少资源消耗至关重要。本文结合 6.x 版本特性，从缓存利用、慢查询诊断、文档模型设计等维度，详解查询优化的实用方案。

高效利用查询缓存：减少重复计算

Elasticsearch 内置多种缓存机制，可自动缓存高频查询结果，避免重复执行相同计算。合理配置缓存策略，能显著降低 CPU 和 IO 开销。

缓存类型及适用场景

Elasticsearch 6.x 主要依赖两种查询缓存：

缓存类型	作用范围	适用场景	缓存策略
Filter 缓存	过滤条件（`filter` 子句）	频繁执行的固定过滤条件（如状态、时间范围）	LRU（最近最少使用）淘汰
请求缓存	聚合结果、`count` 等无排序查询	高频聚合查询（如仪表盘统计）	基于查询哈希缓存结果

核心配置与优化

（1）启用 Filter 缓存

Filter 缓存默认开启，可通过以下配置调整缓存大小（占堆内存比例）：

# elasticsearch.yml 中配置
indices.queries.cache.size: 25%  # 默认为10%，可提升至20%-30%（不超过堆内存的50%）

注意：仅 filter 子句会被缓存（query 子句因需计算得分，不缓存），建议优先用 filter 处理固定条件。

（2）启用请求缓存（Request Cache）

请求缓存默认对所有索引开启，缓存无排序的聚合、count 等查询结果：

# 索引级别开启（默认开启）
PUT my_index/_settings
{
  "index.requests.cache.enable": true
}

不缓存的场景：含 from/size（分页）、sort（排序）的查询，或请求体变化的动态查询。
手动刷新缓存：索引数据更新后，缓存会自动失效；也可手动清除：
```
POST my_index/_cache/clear?request=true
```

缓存最佳实践

对高频固定条件（如 “status: active”），用 filter 而非 query，利用 Filter 缓存。
聚合查询尽量避免排序（如 size:0 仅返回统计结果），以便请求缓存生效。
避免缓存过大导致 OOM：监控堆内存使用，indices.queries.cache.size 不超过堆内存的 30%。

慢查询诊断：定位性能瓶颈

优化查询的前提是找到慢查询的根源。通过监控热点线程、开启慢查询日志，可精准定位低效查询。

1. 查看热点线程

使用 _nodes/hot_threads API 识别占用 CPU 过高的线程，判断是否由查询导致：

GET _nodes/hot_threads

输出解读：重点关注 search 相关线程，若某查询持续占用 CPU 超过 50%，可能存在性能问题（如全表扫描、复杂脚本）。

2. 开启慢查询日志

通过配置慢查询日志，记录超过阈值的查询，便于分析：

# elasticsearch.yml 中配置
index.search.slowlog.threshold.query.warn: 10s    # 警告级别：查询耗时>10s
index.search.slowlog.threshold.query.info: 5s     # 信息级别：查询耗时>5s
index.search.slowlog.threshold.query.debug: 2s    # 调试级别：查询耗时>2s
index.search.slowlog.threshold.query.trace: 500ms # 追踪级别：查询耗时>500ms
index.search.slowlog.level: info                  # 日志级别（记录info及以上）
index.search.slowlog.file.size: 100mb             # 日志文件大小
index.search.slowlog.file.max_files: 5            # 最大日志文件数

日志路径：$ES_HOME/logs/[集群名]_index_search_slowlog.log
分析重点：记录慢查询的 DSL、耗时、扫描文档数，判断是否存在全表扫描（total_shards 过大）、复杂脚本（script_score）等问题。

3. 分析查询执行计划

使用 explain API 查看查询在分片上的执行细节，定位耗时步骤：

GET my_index/_search
{
  "explain": true,  # 开启执行计划解析
  "query": {
    "match": { "title": "elasticsearch" }
  }
}

关注 type（查询类型）、description（查询条件）、time_in_nanos（耗时），判断是否存在低效查询类型（如 wildcard 前缀匹配）。

优化文档模型：避免低效关联查询

Elasticsearch 本质是分布式搜索引擎，而非关系型数据库，复杂的关联查询（如 nested、parent-child）会显著降低性能，应通过反规范化优化文档模型。

1. 避免 `nested` 类型

nested 类型用于存储嵌套文档（如一篇文章的多个评论），查询时需将嵌套文档展开为独立文档，再合并结果，性能比普通查询慢 5-10 倍。

优化方案：
若嵌套层级简单，将嵌套字段扁平化存储。例如：

原nested结构：

{
  "title": "文章1",
  "comments": [  // nested类型
    { "author": "A", "content": "好" },
    { "author": "B", "content": "不错" }
  ]
}

扁平化后：

{
  "title": "文章1",
  "comment_authors": ["A", "B"],  // 提取为数组
  "comment_contents": ["好", "不错"]
}

2. 慎用 `parent-child` 关系

parent-child 用于关联不同文档（如 “订单 - 商品”），查询时需跨文档匹配，性能比 nested 慢 100-1000 倍，且不支持缓存。

优化方案：
通过数据冗余合并文档。例如，将子文档信息嵌入父文档：

原parent-child结构：

// 父文档（订单）
{ "order_id": 1, "user": "张三" }
// 子文档（商品），parent为order_id=1
{ "product_id": 101, "name": "手机", "price": 5000 }

合并后：

{
  "order_id": 1,
  "user": "张三",
  "products": [  // 冗余子文档信息
    { "product_id": 101, "name": "手机", "price": 5000 }
  ]
}

3. 文档模型设计原则

优先扁平化：能在单文档内存储的关联数据，绝不拆分。
容忍数据冗余：以空间换时间，减少查询时的关联开销。
控制文档大小：单文档不宜过大（建议 < 100KB），避免内存压力。

其他查询优化技巧

1. 优化字段类型

对无需分词的字段（如 ID、状态），使用 keyword 类型（比 text 查询更快）。
数字类型优先用 integer/long 而非 text（避免字符串比较开销）。
日期字段用 date 类型（支持范围查询优化）。

2. 避免低效查询模式

禁用通配符前缀查询：*keyword 会导致全表扫描，改用 keyword 类型 + 前缀索引（index_prefixes）。
减少 should 子句数量：bool.should 过多（如超过 1024 个）会触发 max_clause_count 限制，可拆分查询或用 terms 替代。
优化排序：避免用 _score 以外的字段排序（需加载字段值到内存）；若必须排序，对字段启用 doc_values（默认开启）。

3. 合理配置分片与副本

分片数：单个索引主分片数 ≤ 数据节点数（避免分片分散导致查询协调开销）。
副本数：通过增加副本（number_of_replicas: 2）分摊查询压力（读请求可分发到副本节点）。