> 最近帮一个客户排查 Elasticsearch 慢查询问题，过程挺有意思的，记录一下。

## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845?from=20421&%3Bfrom_column=20421&from_column=20421)。


## 背景

客户反馈他们的 ES 集群搜索偶尔会卡顿，P90 在 1.2 秒左右，最慢的能到 2.7 秒。但看监控面板，CPU 利用率很低，IO 也没什么压力，GC 也正常。

这就很奇怪了——资源都是空的，查询凭什么慢？

集群配置不算差：3 个数据节点，每个 32 核 64G 内存（JVM 分了 32G），500G 增强型 SSD 双盘，跑的 ES 9.x。慢查询阈值设的 500ms，一天能攒好几千条慢日志。


## 先确认资源没问题

在动手分析查询之前，先把资源层面的嫌疑排干净。
![Clipboard_Screenshot_1775644354.png](https://developer.qcloudimg.com/http-save/yehe-7348459/54e0bca798bdd1bdbde25c291c3d997c.png)
**CPU**：最大使用率稳定在 5%-7%，峰值也才 8%，资源极度充裕。
![Clipboard_Screenshot_1775644370.png](https://developer.qcloudimg.com/http-save/yehe-7348459/c36c3e4428b68160c76916ce8d1f78fc.png)
**JVM**：Old 区内存稳定攀升，到了某个时间点 Full GC 正常触发、内存完全回收，JVM 运行健康，没有内存泄漏的迹象。
![Clipboard_Screenshot_1775644376.png](https://developer.qcloudimg.com/http-save/yehe-7348459/bfea780b9bf212619bd439049200d483.png)
**磁盘 IO**：基线约 10%，周期性峰值 25%-35%，也没有瓶颈。

三项指标全部正常，可以排除"资源不足导致慢查询"这个方向了。那问题到底出在哪？


## 看看慢查询长什么样

拉了 700 条慢日志下来，发现结构高度一致，都是同一个查询模板，大概长这样：

```json
{
  "size": 40,
  "min_score": 1.0,
  "query": {
    "bool": {
      "filter": [
        { "range": { "publish_time": { "gte": "2024-03-31", "lte": "2026-04-02" } } },
        { "term":  { "is_deleted": "0" } }
      ],
      "should": [
        { "multi_match":   { "query": "关键词A", "fields": ["content^1.0", "title^2.0"], "type": "cross_fields", "operator": "AND", "boost": 2.0  } },
        { "match_phrase":  { "title":   { "query": "关键词A", "slop": 30, "boost": 2.0 } } },
        { "match_phrase":  { "content": { "query": "关键词A", "slop": 30 } } },
        { "multi_match":   { "query": "关键词B", "fields": ["content^1.0", "title^2.0"], "type": "cross_fields", "operator": "AND", "boost": 10.0 } },
        { "match_phrase":  { "title":   { "query": "关键词B", "slop": 30, "boost": 2.0 } } },
        { "match_phrase":  { "content": { "query": "关键词B", "slop": 30 } } }
      ],
      "minimum_should_match": "1"
    }
  },
  "highlight": {
    "fields": {
      "content": {
        "type": "plain",
        "fragment_size": 500,
        "number_of_fragments": 3,
        "order": "score",
        "boundary_scanner": "SENTENCE",
        "boundary_scanner_locale": "zh-CN"
      }
    }
  }
}
```

每次查询返回 40 条文档，带高亮，should 子句数量从 6 到 18 不等（平均 13 个左右）。查询模板是 N 组关键词 × 每组 3 个子句（一个 cross_fields、两个 match_phrase）。

看到这个 DSL 的第一反应是——should 子句是不是太多了？但先别急着下结论，得拿数据说话。


## 火焰图：写入占了大头，搜索其实没什么压力
![Clipboard_Screenshot_1775644466.png](https://developer.qcloudimg.com/http-save/yehe-7348459/ceaf3d45f1533d5153bb250bc82d4846.png)
三个节点都抓了火焰图，各有差异。以其中一个节点为例，CPU 时间分布大概是这样的：

| 路径 | 占比 |
|------|------|
| Replica 写入 | **45.2%** |
| Segment Merge | **19.2%** |
| HighlightPhase | **10.5%** |
| Refresh | 6.1% |
| Primary 写入 | 6.0% |
| Flush | 2.3% |
| 其他 | 1.2% |

三个节点的差异主要在写入侧：有的节点 Replica 写入占大头，有的 Primary 写入多一些，Merge 占比也各不相同。但有一个共同点——**HighlightPhase 在三个节点上都稳定存在**，占比分别是 10.5%、10.7%、6.1%。

写入侧（Replica + Merge + Refresh + Primary + Flush）加起来占了将近 80%。搜索相关的只有 HighlightPhase 那 10% 左右。

也就是说，**集群的 CPU 主要在忙写入，搜索对集群几乎没有压力**。那搜索为什么慢呢？

仔细看 HighlightPhase 的调用链：

```
HighlightPhase
  └─ PlainHighlighter.highlight
       └─ Highlighter.getBestTextFragments
            └─ QueryScorer.init
                 └─ WeightedSpanTermExtractor.getWeightedSpanTerms  (~9.4%)
```

嗯，`PlainHighlighter`，记住这个名字。

顺便提一句，SynonymFilter 在火焰图中有多处散落的小帧，但占比不到 0.1%，采样量极小，不是瓶颈。


## jstack：线程全部空闲，没有锁竞争

三个节点的 jstack 都看了，search 线程池每个节点 49 个线程，采集时刻全部处于 WAITING 状态——等活干呢。

没有死锁，没有 BLOCKED，没有 GC 异常。

不过有个细节值得注意：ES 默认的 search 线程池大小是 `min(32, 核数/2+1) = 17`，但实际有 49 个。说明历史上出现过搜索并发高峰，线程池被撑大过。但采集时刻确实是空闲的，慢查询是偶发性的，不是持续性的并发压力。

jstack 层面没有异常，问题不在线程竞争或 GC 停顿上，出在查询本身的计算逻辑上。


## Profile：真凶浮出水面

开了 ES 的 Profile API，抓了一次典型查询的执行明细。总耗时 2707ms，分布如下：

| 阶段 | 耗时 | 占比 |
|------|------|------|
| Query 阶段 | ~10ms | < 1% |
| Fetch 阶段（最慢 shard） | **2599ms** | **99%** |

Query 阶段只要 10ms！6 个 should 子句的 BooleanQuery，跑完只要 10 毫秒，完全不是瓶颈。

那 2599ms 花在哪了？看 Fetch 阶段各 shard 的明细：

| Shard | Fetch 总耗时 | HighlightPhase | 占比 |
|-------|------------|----------------|------|
| Shard 0 | 544ms | 539ms | 99.1% |
| Shard 1 | 401ms | 390ms | 97.3% |
| Shard 2 | 2599ms | 2573ms | 99.0% |
| Shard 3 | 1450ms | 1436ms | 99.0% |
| Shard 4 | 1183ms | 1160ms | 98.1% |

每个 shard 的 fetch 耗时里，**HighlightPhase 占了 97%~99%**。5 个 shard 并行执行，整体耗时由最慢的 Shard 2 决定。

Query 阶段的详情也看了，完全正常：

```
BooleanQuery（should=6）
  ├─ MultiPhraseQuery（content, slop=30）  ~2ms
  ├─ MultiPhraseQuery（title, slop=30）    ~1ms
  ├─ BlendedTermQuery（cross_fields）      ~1ms
  └─ BoostQuery × N                       ~1ms
```

查询结构本身没有问题，10ms 就跑完了。

到这里根因已经很清楚了：**PlainHighlighter 就是凶手**。


## 为什么 PlainHighlighter 这么慢？

PlainHighlighter 是 ES 默认的高亮器，工作原理比较"笨"：

1. 对每一条命中文档，**重新对整个 content 字段做一次全文 tokenize**——包括跑分词器、同义词扩展，全套流程再来一遍
2. 然后拿查询里的每个子句（`match_phrase`、`multi_match` 等）去逐一匹配，找到高亮片段的位置
3. 40 条文档 × 每条文档几千字的正文 × 十几个 should 子句，全部**串行处理**

这就解释了那个最初的疑问——**为什么 CPU 空载但查询还是慢**。

这不是并发问题，不是资源不足的问题。是单次请求的串行计算量本身就大。整体 QPS 不高，所以 CPU 利用率看起来很低；但每一次查询都要对 40 篇长文做全文重分词 + 复杂 query 匹配，这个计算过程是串行的，单次请求就要花 2~3 秒。

**加机器、扩容，都解决不了这个问题。**


## 交叉验证：不是个例

为了确认结论的可靠性，又额外抓了 4 个不同查询的 Profile，覆盖不同索引、不同关键词、不同 should 子句数量：

| 查询 | 索引类型 | took | should 子句数 | 最慢 shard fetch | Highlight 占比 |
|------|---------|------|-------------|-----------------|---------------|
| 查询 1 | 长文索引 | 2977ms | 8 | 2948ms | 98.7% |
| 查询 2 | 短文索引 | 695ms | 14 | 665ms | 96.1% |
| 查询 3 | 长文索引 | 465ms | 14 | 443ms | 98.0% |
| 查询 4 | 长文索引 | 219ms | 14 | 180ms | 98.3% |

查询 1 的各 shard 明细也很有代表性：

| Shard | Fetch 总耗时 | HighlightPhase | 占比 |
|-------|------------|----------------|------|
| Shard 4 | 2948ms | 2910ms | 98.7% |
| Shard 0 | 2367ms | 2232ms | 94.3% |
| Shard 1 | 2186ms | 2095ms | 95.8% |
| Shard 2 | 251ms | 249ms | 99.1% |
| Shard 3 | 0ms | 0ms | — |

几个有意思的发现：

1. **HighlightPhase 占 fetch 耗时 96%~99%，100% 复现**，其他阶段（FetchSourcePhase、StoredFieldsPhase）均在个位数毫秒，可以忽略不计
2. **Query 阶段始终在 6~26ms**，跟最终 took 完全不成比例
3. **should 子句数量不是决定因素**：查询 1 只有 8 个子句，反而最慢（2977ms）；查询 2/3/4 都是 14 个，反而更快。真正影响耗时的是文档正文字段的长度——字段越长，PlainHighlighter 重分词的开销越大
4. **跨索引结论一致**：短文索引存的是公告（正文较短），长文索引存的是研报（正文很长），同样 14 个子句，耗时差异完全来自字段长度

4 个 Profile 与原始分析结论完全吻合——PlainHighlighter 对大字段的重分词开销是所有慢查询的唯一根因，与集群负载、并发量、should 子句数量均无关。


## 慢日志统计

700 条慢日志的统计结果：

| 指标 | 值 |
|------|-----|
| P50 | 708ms |
| P75 | ~900ms |
| P90 | 1200ms |
| P95 | ~1500ms |
| P99 | ~2200ms |
| MAX | 2700ms |

耗时区间分布：

| 区间 | 数量 | 占比 |
|------|------|------|
| 500ms ~ 1s | 558 条 | 80% |
| 1s ~ 2s | 132 条 | 19% |
| 2s ~ 5s | 10 条 | 1% |
| 5s+ | 0 条 | 0% |

按 should 子句数量分类看：

| 类型 | should 子句数 | 数量 | avg | p50 | p90 | max |
|------|-------------|------|-----|-----|-----|-----|
| A 型（短查询） | 6 | 248 | 823ms | 711ms | 1200ms | 2700ms |
| B 型（中查询） | 12 | 66 | 697ms | 618ms | 1000ms | 1700ms |
| C 型（长查询） | 18 | 386 | 804ms | 730ms | 1200ms | 2300ms |

should 子句从 6 增加到 18，耗时没有线性增长，18 个子句的查询甚至比 6 个还快。再次印证慢的不是 query 阶段，而是 HighlightPhase。

查询特征方面，700 条慢查询 100% 都带 highlight，100% 都是 `type=plain`，100% 都在高亮大文本字段。没有任何异常查询混入，根因就是一个：PlainHighlighter。


## 根因总结

画个图总结一下：

```
慢查询（P50=708ms，P90=1.2s，MAX=2.7s）
│
├─ CPU/IO/GC 全部正常 → 排除资源瓶颈
├─ jstack 线程全部空闲 → 排除锁竞争
├─ Profile: Query 阶段 ~10ms → 排除查询结构问题
│
└─ Profile: Fetch 阶段 99% 耗时在 HighlightPhase
    ├─ PlainHighlighter 对大字段重新全文 tokenize（含同义词）
    ├─ 平均 13.2 个 should 子句，高亮器逐一匹配
    ├─ fragment_size=500，number_of_fragments=3
    └─ 每次查询返回 40 条文档，串行处理
```

这是一个典型的"单次请求串行计算量大"问题，和"并发资源不足"没有关系。整体 QPS 不高，CPU 看起来空载；但每一次查询都要对 40 条文档的大字段做全文重分词 + 复杂 query 匹配，这个计算过程是串行的，单次请求就要花 2~3 秒。

加机器、扩容都解决不了这个问题，根因在查询写法上。


## 怎么解决？

### 核心方案：PlainHighlighter 换成 FVH

这是收益最大的一个改动。FVH（Fast Vector Highlighter）直接读取索引时预建的 term vector，不需要重新 tokenize，速度比 PlainHighlighter 快 10~100 倍。

**第一步：改 mapping，开启 term_vector**

```json
PUT your_index/_mapping
{
  "properties": {
    "content": {
      "type": "text",
      "term_vector": "with_positions_offsets"
    }
  }
}
```

这里 `term_vector` 的值必须是 `with_positions_offsets`，其他值不满足 FVH 的要求。改完 mapping 之后需要对存量数据做一次 reindex，新写入的数据会自动带上 term vector。代价是索引体积会增大约 20%~30%。

**第二步：查询里改用 FVH**

```json
"highlight": {
  "fields": {
    "content": {
      "type": "fvh",
      "fragment_size": 500,
      "number_of_fragments": 3,
      "order": "score",
      "boundary_scanner": "SENTENCE",
      "boundary_scanner_locale": "zh-CN"
    }
  }
}
```

如果业务上需要支持 `cross_fields` 类型的高亮，也可以考虑 `"type": "unified"`，性能介于 plain 和 fvh 之间，兼容性更好。

预期效果：**P90 从 1.2s 降到 200~300ms，P50 从 708ms 降到 100~150ms**。

### 其他可以看看的点

**1. should 子句数量**

查询结构是 N 组关键词 × 每组 3 个子句的固定模板。多组关键词通常是同一查询意图的不同表达方式，每组语义不同，结构本身是合理的。

但每增加一组关键词，就多一个 `match_phrase content` 子句，PlainHighlighter 在高亮阶段需要逐一匹配，子句越多计算量越大。换用 FVH 之后这个问题会大幅缓解。如果业务侧能评估某些关键词组的召回贡献，适当合并语义相近的组，也能进一步降低复杂度。但不建议为了性能强行压缩子句数量，避免损失召回率。

**2. slop 值**

当前大量使用 slop=30/40/50，slop 越大 match_phrase 需要检查的位置组合越多。但 slop 是召回参数，不是纯粹的性能参数，降低 slop 会直接减少命中文档数。

在长文本搜索场景中，同一概念经常跨句子表达，大 slop 是有意为之的设计。贸然统一压低 slop 会漏掉真实相关文档，这是召回率损失，不是噪音过滤。换 FVH 之后 query 阶段只需约 10ms，slop 对整体性能的影响已经可以忽略，没有必要为了性能牺牲召回。

**3. fragment 配置**

`fragment_size` 和 `number_of_fragments` 的调整属于展示效果的取舍，不是性能优化。`number_of_fragments` 从 3 改成 1，用户就看不到文档里其他相关段落了；`fragment_size` 从 500 改成 200，上下文信息会减少。建议跟产品侧确认后再决定，换 FVH 后如果延迟已经满足要求，保持原有配置就行。

## 预期收益

| 优化项 | 实施难度 | 预期收益 |
|--------|---------|----------|
| PlainHighlighter → FVH | 中（需 reindex） | P90: 1.2s → 200ms，降低约 83% |
| 评估 should 子句合理性 | 低 | 换 FVH 后为锦上添花，不建议强行压缩 |
| 按语义评估 slop 值 | 低 | 换 FVH 后优化空间有限，不建议统一压低 |
| 按需调整 fragment 配置 | 低 | 展示效果取舍，需产品侧确认 |

最核心的一条：**把 PlainHighlighter 换成 FVH，这一个改动就能解决 80% 以上的慢查询问题**。


## 写在最后

这个 case 给我的最大感受是：**不要被表面的监控指标迷惑**。CPU 空载不代表没有性能问题，有时候问题藏在单次请求的串行计算里，监控面板上根本看不出来。遇到这种"资源充足但就是慢"的情况，Profile API 和火焰图是最靠谱的排查手段。

另外，PlainHighlighter 在小字段、简单查询的场景下完全够用，但一旦碰上大文本 + 复杂查询的组合，性能会断崖式下降。如果你的业务场景涉及长文搜索 + 高亮，强烈建议一开始就用 FVH 或 Unified Highlighter，别等慢了再改——reindex 的成本可不低。

---

*本文基于火焰图（3 节点）、jstack（3 节点）、ES Profile（5 次采集）、慢查询日志（700 条采样）综合分析*

最近帮一个客户排查 Elasticsearch 慢查询问题，过程挺有意思的，记录一下。

Elasticsearch 实战 | CPU 在摸鱼，查询在搬砖：一次 ES 慢查询的离谱真相

官方产研

云计算

后端

大数据

Elasticsearch慢查询优化实战：揭秘PlainHighlighter性能瓶颈及FVH解决方案。通过火焰图、Profile API分析发现高亮阶段耗时占比99%，改用Fast Vector Highlighter后P90从1.2s降至200ms。适用于腾讯云ES的长文本搜索场景，包含mapping配置、查询改造等完整优化方案。

Elasticsearch Service

JSON

2026采购季 | AI焕新·智启新局

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Elasticsearch慢查询优化实战：揭秘PlainHighlighter性能瓶颈及FVH解决方案。通过火焰图、Profile API分析发现高亮阶段耗时占比99%，改用Fast Vector Highlighter后P90从1.2s降至200ms。适用于腾讯云ES的长文本搜索场景，包含mapping配置、查询改造...

Elasticsearch 实战 | CPU 在摸鱼，查询在搬砖：一次 ES 慢查询的离谱真相-腾讯云开发者社区-腾讯云

Elasticsearch 实战 | CPU 在摸鱼，查询在搬砖：一次 ES 慢查询的离谱真相

Elasticsearch 实战 | CPU 在摸鱼，查询在搬砖：一次 ES 慢查询的离谱真相

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐