1. 从业务痛点聊起：为什么查询越写越慢，索引越建越多
做后端开发或者数据相关的工作，早晚会跟 ElasticSearch 打交道。我最早接触 ES 是因为业务方提了一个需求：要在几千万条订单数据里做多条件组合筛选，还要支持模糊匹配和按时间范围聚合统计。当时 MySQL 已经扛不住了，几个大表的 join 加 like 查询直接能把从库拖死，于是开始调研搜索引擎方案。
刚开始以为 ES 就是个"能全文检索的数据库"，把数据导进去、写几个 match 查询就完事了。真正深入之后才发现，ES 查询的写法、索引设计、分片策略、分词器选型，每个环节都可能成为性能瓶颈。这篇文章把我实际项目中踩过的坑、验证过的查询写法、聚合分析的用法，以及常规文档里不会写的排查思路，系统盘一遍。
适合谁看呢：正在用 ES 做业务查询但总感觉性能不对的开发者，准备从零搭建 ES 查询体系的技术负责人，以及那些被 match、term、bool、aggregation 这些概念绕晕的新手。我会尽量用大白话把原理讲透，再给可以直接抄的实例。
2. 查询方案设计的关键决策：先想清楚再动手
2.1 明确查询场景类型，别一上来就写 DSL
很多人拿到需求就直接写查询语句，结果后面到处打补丁。正确的做法是先梳理业务到底需要哪几类查询能力。
我习惯把 ES 查询场景分成三类。第一类是精确匹配类，比如根据订单号、用户 ID、商品 SKU 查详情，这类查询对响应时间要求极高，通常要求毫秒级返回。第二类是全文检索类，比如根据商品名称、描述做关键词搜索，需要分词、评分排序。第三类是聚合分析类，比如统计某段时间内的销售额、按类目分组计数、计算平均值等。
这三种场景对索引设计和查询写法的影响是完全不同的。精确匹配类字段建议用 keyword 类型，全文检索类用 text 类型并配置合适的分词器，聚合分析类要特别注意 doc_values 的开启。如果一开始没想清楚就建索引，后面改 mapping 的成本极高，甚至需要重建索引。
举一个具体的例子。我之前做一个商品搜索功能，设计 mapping 时把商品名称同时设为 text 和 keyword 两个字段。text 用于 match 查询实现模糊搜索，keyword 用于 term 查询实现精确匹配和聚合。这个设计一开始觉得冗余，但实际运行下来非常合理——因为高频场景是用户输入关键词搜索商品，同时后台需要按商品名精确统计上下架数量，两种查询需求并存。
2.2 分词器选型的背后逻辑
分词器是 ES 查询最容易忽视又最容易出问题的地方。默认的 standard 分词器对于英文场景很友好，但对于中文场景几乎等于没有分词——它会把中文文本按单个字切分，导致搜索结果非常不准。
比如搜索"智能手机"，standard 分词器会切成"智"、"能"、"手"、"机"四个单字，查询"手机"也能匹配到这条文档，但相关度很低，还会把很多不相关的文档带出来。用过 ik 分词器的都知道，ik_smart 和 ik_max_word 两种模式差别很大。ik_smart 做最粗粒度的切分，适合搜索场景；ik_max_word 做最细粒度切分，适合索引场景，能保证召回率。
实际项目中我更推荐一种组合方案：索引时用 ik_max_word 最大限度切分，保证各种查询词都能命中；查询时用 ik_smart 精准切分，减少无效匹配。这里有一个很多人不知道的坑：如果索引和查询用的分词器不一致，某些词可能匹配不上。所以自定义分析器时，建议同时指定 index 和 search 两个分词器，而不是只配一个。
再补充一点自定义词典的经验。业务里有一些行业黑话，比如"机皇""暗黑系"这类词，ik 分词器默认词典识别不了，会被切成单个字。后来我在 ik 的配置目录下维护了一个自定义词典文件，把这些词加进去，分词准确率提升了很多。词典文件是热加载的，修改后不需要重启节点，但需要在 IKAnalyzer.cfg.xml 里配置好词典文件路径。
2.3 索引分片与副本设计的经验谈
分片数量是最容易被拍脑袋决定然后又不好改的参数。分片数等于数据被水平切分的份数，每个分片本质上是一个 Lucene 索引。分片过少，单分片数据量太大，查询和写入性能都会下降；分片过多，集群的元数据管理开销增大，每个分片还要占用一定的文件句柄和内存。
我的经验公式是：单分片数据量控制在 20GB 到 40GB 之间比较合理，分片总数最好不要超过节点数的三倍。当然这只是一个经验值，实际还要看查询复杂度和写入并发。举个例子，一个集群有 3 个数据节点，预估数据总量 100GB，单分片按 30GB 算，需要 3 到 4 个分片，那么每个节点大概分摊 1 到 2 个分片，这个量级是健康的。
副本数在查询压力大的场景下很关键。副本不仅能提高可用性，还能分摊查询流量。ES 的查询会随机路由到主分片或副本分片上，副本数越多，单个分片承受的查询压力就越小。但副本多也意味着存储成本翻倍，同时写入性能会略有下降，因为每个副本都要同步数据。
我之前优化过一个订单查询服务，数据量不大但 QPS 很高，大概每分钟几万次查询。把副本数从 1 调到 2 之后，查询平均响应时间从 80ms 降到了 45ms，效果非常明显。如果 QPS 不高，副本设 1 就足够了，没必要白白浪费存储。
3. 查询 DSL 核心写法与参数深挖
3.1 match、term、terms 的使用边界
查询 DSL 里最基础也最容易混淆的是 match 和 term。我用一个表来说明它们的核心区别：
| 对比维度 | match | term / terms |
|---|---|---|
| 分词处理 | 查询词会被分析器分词 | 查询词不会被分词，整体匹配 |
| 适用场景 | 全文检索、模糊匹配 | 精确匹配、过滤、聚合 |
| 字段类型 | 一般用于 text 字段 | 用于 keyword 或数值类型 |
| 匹配逻辑 | 分词后任意一个词命中即可 | 必须完全等于查询值 |
很多人踩过的坑是拿 term 查询 text 字段，结果什么都查不出来。原因是 text 字段在索引时被分词了，term 查询拿完整的查询词去找词项，除非这个词恰好是分词结果，否则匹配不到。比如索引时"智能手机"被切成"智能"、"手机"两个词项，用 term 查"智能手机"就找不到了，但查"手机"可以命中。
如果字段已经被设计成 text 类型，但业务上又需要精确匹配，推荐使用 multi-fields 方式，在 mapping 里给这个字段同时配一个 keyword 子字段。这样既可以用 match 做全文搜索，也可以用 term 做精确过滤。
terms 是 term 的多值版本，用来查询字段值等于给定数组中任意一项的文档。比如批量查询多个订单状态：terms 查询在底层会被转成 bool should 子句组合，但写法上更简洁，性能上也没有明显差异。
3.2 bool 组合查询的编排技巧
bool 查询是 ES 里最核心的组合查询结构，包含 must、should、must_not、filter 四种子句。理解这四种子句的区别，是写出高性能查询的关键。
must 子句的语义是"文档必须满足这些条件"，并且会参与相关度评分。filter 子句也是"文档必须满足条件"，但不会参与评分。这一点在性能上的差别很大——filter 子句的结果会被缓存，而 must 子句的结果不会。如果一个条件只是缩小范围而不影响排序，应该放到 filter 里而不是 must 里。
举个例子，查询某个类目下包含"手机"关键词的商品，且价格在 1000 到 5000 之间。这里"手机"是搜索关键词，需要参与相关度排序，放进 must；类目和价格范围是限定条件，不影响相关性，放进 filter：
{ "query": { "bool": { "must": [ { "match": { "name": "手机" } } ], "filter": [ { "term": { "category_id": 1001 } }, { "range": { "price": { "gte": 1000, "lte": 5000 } } } ] } } }should 子句是"或"的关系，但它有个微妙的逻辑：在 bool 查询里，如果同时存在 must 或 filter，should 子句不是必须命中的，它只是提升文档得分；只有当 bool 查询里只有 should 子句时，文档才必须至少命中其中一个条件。这个逻辑刚接触时很容易搞混。
我在实际项目中经常用 should 来做多字段权重搜索。比如搜索商品，希望名称匹配的权重高，描述匹配的权重低：
{ "query": { "bool": { "must": [ { "match": { "name": "蓝牙耳机" } } ], "should": [ { "match": { "description": "蓝牙耳机" } } ], "minimum_should_match": 0 } } }这里 must 保证一定按名称匹配，should 让描述也匹配的文档得分更高，排序更靠前。
3.3 range 查询的时间边界问题
时间范围查询是高发问题重灾区。ES 里日期字段默认被解析为 UTC 时间存储，如果查询的时候不指定时区，会跟北京时间差 8 小时，导致统计数据不准或者查不到数据。
我之前就出过一个问题：业务方反馈当天订单在后台查不到，排查了半天，最后发现是因为查询条件里的时间用了本地时间，但没有指定 time_zone 参数，ES 按 UTC 解析，导致查询范围整体偏移了 8 小时。正确写法是在 range 查询里显式指定时区：
{ "query": { "range": { "order_time": { "gte": "2024-06-01T00:00:00+08:00", "lte": "2024-06-01T23:59:59+08:00", "time_zone": "+08:00" } } } }还有一个需要注意的细节是边界值。需求里如果要求"查询截止到当天"的业务，用 lt 还是 lte 要提前想清楚。ES 对日期字符串的解析精度很高，如果写入的数据精确到纳秒级，lte 当天 23:59:59 仍然会漏掉 23:59:59.999 的数据。更稳妥的做法是用 lt 加第二天零点，保证不会漏数据。
3.4 嵌套查询与父子文档怎么选
业务中经常遇到一对多的数据结构，比如一个订单包含多个商品项。在 ES 里有两种建模方式：nested 嵌套类型和 parent-child 父子关系。
nested 类型把整个数组对象作为一个独立的隐式文档存储，查询时通过 nested 查询定位。它的优点是查询性能好，因为关联数据在同一个分片且物理存储接近；缺点是更新成本高，修改数组里任意一个元素都要重建整个嵌套文档。
parent-child 关系则是把父子文档分别存储，通过 join 字段关联。它的优点是子文档可以独立更新，适合子文档频繁变动的场景；缺点是查询性能比 nested 差，因为需要跨文档关联。
我之前做的一个订单系统，订单项包含商品名称、数量、价格、退款状态等字段，退款状态会频繁变更。最初用 nested 建模，每次退款状态变更就要重建整个订单文档，写入压力很大。后来改成 parent-child 关系，子文档单独更新，性能问题就解决了。
如果只是查询嵌套数据，nested 是更推荐的选择。有一个细节需要注意：nested 查询的结果里，_source 返回的是整个嵌套数组，而不是命中的那一条。如果需要精准定位到命中的嵌套对象，需要用到 inner_hits 特性：
{ "query": { "nested": { "path": "order_items", "query": { "bool": { "must": [ { "match": { "order_items.goods_name": "手机壳" } } ] } }, "inner_hits": {} } } }加了 inner_hits 之后，查询结果里会额外返回命中的嵌套对象详情，这在后台做高亮显示时特别有用。
4. 聚合分析：从统计需求到执行原理
4.1 聚合的核心机制与执行时机
ES 的聚合分为桶聚合、指标聚合和管道聚合三大类。桶聚合是按条件分桶，类似 SQL 里的 group by；指标聚合是计算平均值、最大值、最小值、总和等，类似 SQL 里的聚合函数；管道聚合是聚合结果的二次计算，比如对聚合结果再求平均值。
理解聚合的执行时机很关键。聚合是在查询命中结果的基础上进行的，也就是说聚合和查询是分离的两个阶段：先查文档，再对结果做聚合。这个机制意味着，如果查询条件很宽泛，命中了大量文档，聚合的计算量会非常大。
聚合执行包含两个阶段：每个分片先在本地对分片内数据做聚合，产生一个中间结果；然后协调节点把所有分片的中间结果合并，得到最终结果。这里有个容易忽略的性能隐患：如果分片数量很多，合并阶段的网络开销会很大。所以做聚合时，分片数不宜过多，否则聚合响应时间会明显增加。
4.2 常用聚合实例：分组统计与时间直方图
需求场景：统计每个商品类目的销售额和订单数，并按天展示趋势。这需要用到 terms 聚合和 date_histogram 聚合。
date_histogram 按日期分组有个重要参数 fixed_interval 和 calendar_interval。在 7.x 之后的版本里，calendar_interval 用于日历单元（如 month、week、day），它会根据日历调整边界；fixed_interval 用于固定间隔（如 30s、10m），适合固定时间窗口的统计。如果按自然月统计，用 calendar_interval 是正确的选择；如果要按每 30 天一个窗口统计，应该用 fixed_interval。
一个具体的聚合查询示例：
{ "size": 0, "aggs": { "category_sales": { "terms": { "field": "category_id", "size": 10 }, "aggs": { "total_amount": { "sum": { "field": "pay_amount" } }, "order_count": { "value_count": { "field": "order_id" } }, "daily_trend": { "date_histogram": { "field": "order_time", "calendar_interval": "day", "format": "yyyy-MM-dd" } } } } } }关于聚合的两个重要参数得仔细说。terms 聚合的 size 不是简单地控制返回桶数量，它还影响文档采集精度。es 默认情况下，每个分片按词频取前 size 个桶，最后合并时只保留全局前 size 个桶。如果分片很多且数据分布不均匀，这种方式可能漏掉一些真实的高频桶。要解决这个问题，可以通过 shard_size 参数放大每个分片返回的桶数。比如 final size 是 10，shard_size 设为 1000，这样每个分片返回 1000 个桶，最终合并结果更准确。
另一个参数是 min_doc_count，它表示桶最少要包含多少文档。默认情况下，terms 聚合会针对每个分片设置不同的最小文档数，以避免返回大量全局计数为零的桶。但如果你的数据总量不大，又想看到所有类目的统计，可以设置 min_doc_count 为 1。
4.3 聚合排序的隐藏逻辑
聚合排序和普通字段排序不太一样。terms 聚合默认按 doc_count 降序排列，如果业务需要按聚合指标排序，比如按销售额从高到低排列类目，需要借助 order 参数：
{ "aggs": { "category_sales": { "terms": { "field": "category_name", "order": { "total_amount": "desc" } }, "aggs": { "total_amount": { "sum": { "field": "pay_amount" } } } } } }这里的关键点是 order 里引用的 total_amount 是子聚合的名称。ES 在执行时先完成子聚合的计算，再根据子聚合结果进行桶排序。这就意味着，排序操作是基于全量聚合结果进行的，在数据量大时可能比较慢，尤其当桶数量多且需要精确排序时。如果业务上对排序精度要求不高，可以通过设置 batched_reduce_size 参数，让 ES 分批处理 reduce 阶段的数据，减少内存压力。
我实际测试过一组数据：1000 万条订单记录，terms 聚合按类目分组，再按销售额排序。默认配置下响应时间约 300ms，把 shard_size 从默认值调大到 500 后，响应时间降到 180ms 左右，准确率也没有下降。原因在于默认 shard_size 太小，导致每个分片返回的桶数不够，最终合并时发生了二次汇总，增加了额外开销。
4.4 聚合内存与性能问题的排查经验
聚合是 ES 内存消耗的大户，特别是高基数字段（字段值的数量非常多，比如用户 ID、订单号）。在做大基数聚合时，如果 terms 聚合没有设置合理的 size，ES 会把所有分片上的全部词项都收集到协调节点，内存瞬间就爆了。
我在线上遇到过集群红色健康状态的事故，原因就是一次聚合查询，terms 聚合的 size 设置成了 1000000 没加限制，直接导致协调节点 OOM 崩溃。后来给聚合查询加了一层保护：在网关层对 size 参数做校验，超过 10000 就拒绝执行，同时让业务方拆分查询条件，缩小数据范围后再做聚合。
做聚合查询的四个排查建议：
- 用
_search的profile: true查看聚合阶段耗时，区分是分片聚合慢还是 reduce 阶段慢 - 监控聚合内存占用，重点是
fielddata内存使用量。text 字段默认关闭 fielddata，如果开启后内存增长异常，优先检查是否有高基数 text 字段 - 分析节点 JVM 堆使用率，聚合前和聚合后的差值可以大致估算单次聚合的内存开销
- 高基数聚合优先考虑用
composite聚合做分页拉取，它通过游标方式分批次返回桶结果，避免一次性把所有桶结果都加载到内存
composite 聚合的写法比 terms 稍复杂，但应对高基数场景非常有效：
{ "size": 0, "aggs": { "user_buckets": { "composite": { "sources": [ { "user_id": { "terms": { "field": "user_id" } } } ], "size": 100 } } } }查询结果里会返回一个after_key字段，把它的值作为下一次查询的after参数传入，就能一页一页拉取所有用户的统计结果，内存占用始终可控。
5. 查询性能排查与优化实录
5.1 慢查询定位：slowlog、profile 与 explain
ES 查询慢的原因千奇百怪，学会定位是优化的第一步。我一般按照三个层次来排查：先看网络和客户端有没有超时，再看 ES 内部查询耗时，最后看具体是哪个子查询吃掉了大部分时间。
慢查询日志（slowlog）是最基础的手段。在索引设置里开启慢查询日志，设置阈值：
{ "index.search.slowlog.threshold.query.warn": "2s", "index.search.slowlog.threshold.query.info": "500ms", "index.search.slowlog.threshold.fetch.warn": "1s", "index.search.slowlog.level": "info" }这样超过阈值的查询就会被记录到日志，可以定期分析慢查询模式，找出耗时 query 共性，比如是否都带了某个大范围 range 查询，或者都存在跨多索引查询。
profile API 用于拆解单条查询的每个步骤耗时。在查询体里加上"profile": true，返回结果里可以看到每个分片在query、collector、reduce阶段的耗时，以及 Lucene 内部的每个子查询耗时。有一次我排查一个"查询明明走了 filter 还是很慢"的问题，使用 profile 后发现 filter 内部其实执行了两个子查询，其中一个是对超大 in 集合的 terms 查询，共有几十万个词项。改用 join 字段优化后，耗时直接下降了 90%。
explain API 用来查看单条文档为什么会被查询命中，以及在文档内部得分是怎么计算的。当相关度排序不符合预期时，explain 能告诉我们每个词的 tf-idf 或 BM25 得分占比，帮助定位是否是分词器导致的关键词被拆错。
5.2 常见性能瓶颈与对应解法速查
这里整理成一张表，方便直接对照排查：
| 问题表现 | 可能原因 | 优化方案 |
|---|---|---|
| match 查询召回过多且相关性差 | 分词器切分粒度太细 | 自定义分析器，索引用 ik_max_word，查询用 ik_smart，补充自定义词典 |
| 查询结果不稳定，抖动明显 | 分片数过多或过少 | 控制单分片数据量 20-40GB，保持合理分片数 |
| filter 查询没起到加速效果 | 过滤条件写进了 must 而不是 filter | 将不影响评分的条件全部放入 filter 子句 |
| 大范围 group by 导致内存溢出 | terms 聚合 size 过大或高基数字段 | 限流、拆分查询条件，考虑改用 composite 聚合 |
| 查询结果高亮不准确 | 高亮字段不是 text 类型或没有开启相关参数 | 配置高亮字段为 text 类型，必要时用 unified 高亮器 |
| 深分页查询越来越慢 | 使用 from + size 进行深分页 | 改用 search_after 或 scroll，避免大 offset |
| 数据库同步到 ES 后查询不到新数据 | 没有设置 refresh_interval 或写入后未刷新 | 业务可接受的范围内调高刷新频率，或写入后显式 refresh |
5.3 深分页问题的三个替代方案
from+size 分页在页数深的时候性能急剧恶化，这个坑几乎每个用 ES 的人都会碰到。原因在于 ES 必须先取回前 from+size 条文档的排序信息，再丢弃前 from 条，所以 from 越大，协调节点的内存和 CPU 开销越高。
第 21 页之后的数据，每页查询都可能上秒级。解决方案我按使用场景区分：
第一种是 scroll 滚动查询，适合一次性拉取大量数据做离线处理，比如数据同步、导出。scroll 会生成一个快照上下文，后续请求基于这个上下文持续返回数据，直到显式清除。需要注意 scroll 保留时间不宜过长，否则会持续占用内存。用完必须调用 clear_scroll 清理快照。
第二种是 search_after 分页，适合用户翻页的实时查询场景。利用上一页最后一条记录的排序值作为下一页查询的起始位置，性能稳定，不受页数影响：
{ "size": 10, "sort": [ { "order_id": "asc" } ], "search_after": [10023456] }第三种是 pit（Point In Time）结合 search_after，适合在索引有大量写入、排序结果需要保持稳定的场景。pit 相当于固定了一个视图快照，search_after 在 pit 上执行能保证翻页不受新写入文档的干扰。这个组合也是我在做日志检索翻页时最常用的方式。
5.4 通过建立索引别名实现零停机优化
索引 mapping 设计有问题时，或者需要切换分词器时，直接修改设定是不可能的——ES 的 mapping 一旦创建就无法变更字段类型。常规做法是重建索引，但重建期间不能让业务停服。
我用的方案是索引别名加重建流程配合。先把索引名全部用别名引用，查询走别名，业务层感知不到底层的物理索引名。需要迁移数据时执行五步流程：
- 新建目标索引，设置新的 mapping 和 settings
- 用 reindex 接口从旧索引迁移数据到新索引
- 验证新索引的数据量与旧索引一致
- 把别名指向新索引，同时解除旧索引的别名
- 确认运行稳定后删除旧索引
这个方案我用了很多次，每次都是线上平滑切换。需要注意 reindex 过程中如果旧索引持续有大量写入，最终数据量会有短暂不一致，需要在切换前做一次增量同步，或者尽量在业务低峰期操作。另一个细节是切换别名时，可以先切一个副本节点验证，确认无误后再切另一个。
6. 一段真实项目的查询架构演进
最后分享一个完整的案例链条。某电商后台系统，早期我负责订单查询模块的重构。初始版本的查询逻辑是这样的：所有查询都用 match，所有字段都是 text 类型，排序靠 ES 默认评分，翻页用 from-size。
上线一个月，问题陆续暴露：商品描述字段分词后匹配到大量无关文档；按订单状态筛选时误匹配了状态包含关系；后台订单列表翻到十几页就开始超时。当时的 ES 集群有 5 个节点，订单索引 10 个分片，单分片约 25GB 数据。
我做的改动按优先级排序：
第一，重设计 mapping，把所有精确匹配字段改为 keyword 类型；文本检索字段保留 text 但配置 ik 分析器，同时增加 keyword 子字段用于需要精确聚合的场景。第二，统一查询模板，把状态、时间范围、类目过滤全部放进 filter 子句，搜索结果相关度排序不再被过滤条件干扰。第三，把翻页改成 search_after 配 pit 模式，同时限制最大翻页深度。
改完后，核心查询接口的平均响应时间从 160ms 降到了 28ms，p99 从 600ms 降到 120ms，调用方的超时率基本归零。更明显的变化是集群 CPU 占用从 70% 降到了 35%，之前因为查询太慢加的两台节点，流量切换之后明显空闲了下来。
除了性能提升，有一个体验也很重要：排查问题变得简单了。之前所有查询都走 match，杂七杂八的条件混在一起，出了相关性偏差很难定位。现在每个查询是明显的 bool 结构，各层条件负责什么一目了然，不管是开发还是运维同学都能快速读懂查询意图。
7. 我在 ES 查询实践中的几个额外建议
关于分片数，不要迷信"分片越多越好"这个说法。分片多确实能提升写入并发，但同时会拖累聚合和排序性能。我见过一个集群，36 个分片跑 5 亿数据，聚合查询动辄 3 秒以上。把分片合并到 12 个之后，聚合查询直接到了 500ms 左右。写入并发虽然有所下降，但业务写入量远没到瓶颈，这个取舍非常划算。
关于字段类型，能用 keyword 就不建议用 text。搜索引擎的全文检索能力很重要，但不是所有字段都需要全文检索。状态码、用户 ID、类型标记这些字段用 keyword 就够了，硬用 text 只会增加存储和分析器的负担，还可能带来离谱的匹配问题。
关于聚合内存，设置search.max_buckets参数很关键。es 默认是 10000 个桶，对于大多数场景这个上限是足够的。如果有非常规统计需求需要突破这个上限，要对内存占用做充分评估，尤其要注意文档数乘以分桶数的情况下，协调节点的压力非常大。
关于缓存，ES 的 filter 缓存默认是 LRU 管理的，每 1GB 堆内存默认只给 filter 缓存留 10%。在实际项目中观测到，查询模式相对固定时，把indices.queries.cache.size调大到 20% 可以获得非常明显的性能提升。但如果是频繁变化的查询条件，缓存命中率低，调大这个值反而浪费内存。
关于日常巡检，建议养成定期看慢查询日志和集群监控指标的习惯。我一般是每天拉一次昨天所有超过 500ms 的 query，按来源和模式分类，看有没有新出现的性能异常。很多潜在问题在爆发之前就已经在日志里露出苗头了，比如某个查询开始偶发 1 秒以上的延迟，再过几天可能就变成常态了。
ES 的查询优化是一个持续迭代的过程，不存在一次配置就永远最优的方案。随着数据量的增长、查询模式的演变，索引设计和查询写法都要跟着调整。只要掌握了每个参数背后的原理，再加上实际业务场景的数据反馈，就能在搜索引擎这条路上走得越来越稳。
