elasticsearch查询性能优化需依次执行五步：一、开启慢查询日志并分析aggs嵌套、range未缓存、wildcard前导通配等问题；二、将非评分条件移至filter、减少_source、用固定时间戳替代now-7d/d、替换*开头wildcard；三、控制分片大小在20gb–50gb，对历史索引shrink，副本数设为2，避免主副分片同节点；四、启用request cache，调大query cache至堆内存20%，用constant_keyword封装稳定过滤条件，禁用非必要doc_values；五、对只读索引force merge至1个segment，重建时启用index.sort.field排序，低峰期执行并监控磁盘≤85%。

如果您在使用 Elasticsearch 进行查询时发现响应延迟高、超时频发或节点负载异常上升，则可能是由于查询 DSL 不合理、分片设计失当或缓存未有效利用所致。以下是解决此问题的步骤：

一、开启并分析慢查询日志

慢查询日志是定位性能瓶颈的第一手依据，它能精确记录超过阈值的查询语句、耗时及执行阶段信息。启用后可结合 profile API 进一步下钻到 QueryPhase 与 FetchPhase 的耗时分布。

1、编辑 elasticsearch.yml 配置文件，添加以下参数：

2、设置索引级慢查询阈值（以 products 索引为例）：

3、重启节点或使用动态 API 启用日志：

4、在日志目录中查找 slowlog 文件，筛选出 query.warn 级别以上的记录，重点关注 aggs 深度嵌套、range 查询未命中缓存 和 wildcard 前导通配符 等模式。

二、优化查询 DSL 结构

ES 查询性能高度依赖 DSL 的语义合理性。Filter 上下文可复用缓存且跳过打分，而 Query 上下文强制参与评分计算并绕过部分缓存机制。错误的上下文混用是慢查询主因之一。

1、将所有非相关性排序需求的条件迁移至 filter 子句：

2、禁用全文检索中不必要的 _source 返回，仅请求必需字段：

3、对日期范围查询避免使用 now-7d/d 这类动态表达式，改用固定时间戳提升请求缓存命中率：

4、替换 * 开头的 wildcard 查询为 keyword 字段的 term 查询或 prefix 查询：

三、调整分片与副本配置

分片数量直接影响协调节点的扇出开销与结果合并成本。过多小分片导致 Lucene segment 数量激增，深度遍历耗时上升；过少大分片则无法充分利用多核并行能力。

1、评估单分片大小，确保其落在 20GB–50GB 区间内：

2、对写入停止的历史索引执行 shrink 操作，合并主分片数：

3、为高频读场景增加副本数至 2，使查询请求自动负载均衡至多个副本分片：

4、检查集群分片分配状态，禁止将多个主分片与对应副本共置于同一物理节点：

四、启用并调优查询缓存

Elasticsearch 提供 Request Cache 与 Query Cache 两级缓存机制。Request Cache 缓存整个 Shard 级查询结果，仅对 size=0 或聚合类查询生效；Query Cache 缓存 Filter 子句的布尔匹配结果，复用粒度更细。

1、确认 request cache 已对目标索引启用：

2、增大 indices.queries.cache.size 至堆内存的 20%（默认为 10%）：

3、对恒定不变的过滤条件（如 status: "published"）显式封装为 constant_keyword 类型字段，强制进入 Query Cache：

4、禁用不必要字段的 doc_values（如仅用于 display 的 text 字段），减少缓存元数据体积：

五、执行段合并与索引预排序

持续写入会生成大量小 segment，每次查询需遍历全部 segment 并合并结果。force merge 可将小 segment 合并为大 segment，显著降低查询时的 segment 扫描开销。同时，Index Sorting 可让 Lucene 在 segment 内部按指定字段物理排序，加速 range 查询与 top-k 排序。

1、对只读索引执行 force merge，将最大 segment 数限制为 1：

2、重建索引时启用 index.sort.field 与 index.sort.order 参数：

3、验证排序效果，确认新索引的 segments 数量下降且 range 查询响应时间缩短：

4、注意：force merge 是 I/O 密集型操作，应在业务低峰期执行，并监控磁盘使用率是否突破 85%：