平时写接口和调业务逻辑的时候大家可能都有同感Elasticsearch 的查询语法说简单也简单但真到了线上排查问题或者突然要写一个稍微复杂的聚合统计时往往还是得翻文档、翻历史记录。我自己的习惯是每次在项目里踩过一个查询相关的坑或者找到一个很顺手的写法都会随手记一笔。时间长了这些零散的记录反而成了最实用的参考资料。这篇文章就把我手头积累的 Elasticsearch 查询实例和相关的排查心得整理出来包括 match、term、bool、聚合、分页、深分页这些高频场景也聊聊我在实际项目里怎么排查慢查询、怎么避免数据查不到或者聚合结果不准这类问题。无论你是刚开始接触 ES还是已经写了一段时间查询 DSL这些记录应该都能给你一些参考。这里记录的东西大多来自我在某个日志分析项目和一套商品搜索服务里的实际实践。模拟项目里我主要负责日志检索和数据看板部分的开发期间写过大量的 ES 查询也踩过不少典型的坑。下面就从最基本的查询原理开始一步步把这些实例掰开揉碎讲清楚同时把对应场景下的常用参数和后遗症一并说出来。1. 动手写查询前的准备工作很多人在写 ES 查询的时候习惯一上来就拼 DSL查不到了再回头慢慢调。但在我的实际操作经验里真正高效的流程是先摸清楚索引的映射和文档的结构再动手写查询。这一步如果省了后面大概率会陷入 match 查不到数据、term 查出来一串不该有的结果等连环坑。1.1 先搞清楚你是 text 还是 keyword想搞清楚查询行为必须先理解 ES 里最核心的字段类型差异。text 类型默认会经过分析器处理也就是分词、转小写、过滤停用词等keyword 类型则相反它把整个输入作为一个整体索引不分词。这就直接决定了后续查询用的是 match 还是 term。我举一个自己的例子。模拟项目 X 的日志系统里有一个字段叫message类型是 text另外还有一个字段叫level类型是 keyword。一开始我看到日志里level的值写的是ERROR我就用 match 查询去搜结果也能搜到但后面真正的问题出现在搜索包含空格的标签字段时。标签字段用了 text 类型我把 Internal Server Error 这个整体标签放到 term 查询里结果一条都查不出来因为 text 字段已经被拆成了 internal、server、error 等词元term 查询要求的是完全匹配自然匹配不上。后来把标签字段改成 keyword问题才真正解决。这里给大家一个非常实用的判断标准如果你的字段需要被精确匹配、被用于聚合、或者被用于排序那就应该用 keyword只有当你需要做全文检索也就是希望输入小写关键字时还能匹配到 Error 这种大小写混合文本才用 text。在资源充足、场景严格的情况下甚至可以采用多字段方式定义一个子字段同时满足两类查询需求。1.2 读取索引映射的实用方法怎么快速确认字段类型直接在 Kibana 的 Dev Tools 里执行GET /your_index/_mapping如果你没有 Kibana用 curl 也可以curl -X GET localhost:9200/your_index/_mapping?pretty返回的内容里会列出每个字段的type。我习惯在动手写任何复杂查询前先扫一眼这个结果尤其注意嵌套对象里那些容易忽略的子字段。说实话很多查询结果和预期不一致的情况问题根源都不在 DSL 语法上而在字段映射上。比如你明明觉得某个字段能聚合结果一查发现它是 text 类型聚合直接报错或者返回的 buckets 非常奇怪就是因为映射不对。1.3 理解 _source、_id 和查询返回关系还有一个容易被忽略的地方ES 默认会把整个文档的原始 JSON 放在_source里返回。有些人在查询结果里看不到某个字段第一反应是查询条件写错了其实只是那个字段没有存到_source里或者是被fields参数过滤掉了。我处理过的某项目中有个索引因为历史原因禁用了_source后面排查问题时就特别费劲。所以如果要长期依赖 ES 查询排查业务数据我的建议是不要轻易禁用_source。虽然它会占一点存储空间但在调试和追溯问题上省下的时间远远值回这点磁盘开销。如果你确实需要节省空间可以设置_source的 includes 和 excludes而不是完全关闭。2. 高频查询实例解析准备工作做完了下面进入到具体查询实例。这块内容我按照日常使用频率排列先是全文检索里最常用的 match 系列然后是精确查询的 term、terms、exists再是组合查询 bool最后是范围查询 range。2.1 match 查询的常见用法和坑match 是最常用的全文检索查询但正因为常用很多人反而不知道它的底层行为。match 查询执行之前会先对查询字符串做分析然后拿着分析出来的词项去倒排索引里找。举个例子你输入match: {message: Elasticsearch query}ES 大概率会先分词为 elasticsearch 和 query 两个词项再去匹配。这里有一个操作符参数我很常用GET /my_logs/_search { query: { match: { message: { query: order failed refund, operator: and } } } }默认情况下match 使用的是 or 逻辑也就是说多个词只要有一个匹配上文档就可能被召回。这在很多时候会带回不少噪音数据。如果你希望结果更精确把operator改成 and要求所有词项都必须匹配这样召回结果通常会更接近预期。另外配合minimum_should_match可以控制至少需要几个词项匹配比如 75% 或者 2这在召回率和精确度之间调节特别好用。关于 match 还有一点必须说它受分词器影响极大。默认的 standard 分析器会做小写化和按标点拆分但如果你用了 ik 分词这类中文分析器查询行为又不一样。所以如果你发现某些词明明存在却搜不出来要重点排查分析器配置。2.2 term 与 terms 精确查询term 查询是精确匹配不对查询词做分析而且是针对倒排索引中的词项做完全查找。所以在匹配 keyword 字段或者数值类型字段时应该用 term 而不是 match。举个例子查询状态码为 500 的日志GET /nginx_logs/_search { query: { term: { status_code: { value: 500 } } } }这里 value 可以直接填数字也可以填字符串具体看字段映射。如果状态码在映射里是 long 类型填 500 字符串通常也没问题ES 会自动做类型转换。但如果是 keyword 类型建议严格按实际的字符串值查注意不要带多余空格。terms 查询是一次查多个值类似 SQL 里的 IN。比如查状态码是 400、404、502 的所有请求GET /nginx_logs/_search { query: { terms: { status_code: [400, 404, 502] } } }terms 的查询逻辑是只要匹配其中一个就返回这里有个细节要注意terms 查询内部是 should 逻辑并且 minimum_should_match 默认为 1。如果字段值较多建议把数组大小控制在合理范围内免得产生过大的查询请求体。我在实际项目里优化过一个接口原来每查询一次要拼几十个 ID 的 terms整个请求体非常大后来改成把 ID 列表提前维护成一张映射表查询时用更精简的过滤条件性能明显改善。2.3 bool 组合查询must、should、filter 的正确姿势bool 是 ES 查询中几乎绕不开的组合查询结构它的核心价值在于可以把多个条件组合起来同时精确控制每个条件对评分的影响。常见的结构是GET /orders/_search { query: { bool: { must: [ { match: { product_name: 手机 } }, { term: { status: PAID } } ], filter: [ { range: { created_at: { gte: 2024-01-01 } } } ] } } }must 子句里的条件会同时影响相关度评分filter 子句则只做过滤不参与评分从而可以利用缓存提升性能。这里我想特别强调如果你只是想做过滤不关心关键词相关度排序那就把条件放在 filter 里。比如时间范围、状态值、类型标签这些都适合放 filter。这样既加快了查询速度又避免了一些不必要的算分开销。must_not 也可以放在 filter 面上含义是排除指定条件的文档同样不参与评分。should 比较特殊在 bool 查询中如果没有 must 或 filter那至少一个 should 条件必须满足如果有 must 或 filter那 should 只是提升相关度并不强制满足。利用这个特性可以实现搜索结果优先展示带图商品这类业务需求。我印象很深的一次优化就是来自某商城检索服务的经验原来所有过滤条件全放在 must 里查询响应时间在高峰时接近 800 毫秒。排查后发现很多条件比如类目 ID、库存状态根本不需要参与相关度评分我把它们挪到 filter 之后同样的数据规模下响应时间直接掉到 100 毫秒左右。这就是 bool 查询结构规范化的价值。2.4 range 范围查询和其他常用查询range 查询主要用于数值和日期范围过滤。最基本的日期范围GET /app_logs/_search { query: { range: { timestamp: { gte: 2024-11-01T00:00:00, lte: 2024-11-30T23:59:59 } } } }gte、lte、gt、lt四个参数分别表示大于等于、小于等于、大于、小于。对于日期类型还可以配合时间数学表达式比如GET /app_logs/_search { query: { range: { timestamp: { gte: now-7d/d, lt: now/d } } } }这段的意思是查询最近 7 天每一天从 0 点开始到当前日期的数据。now-7d/d里的/d表示向下取整到天。这种写法在数据看板和定时报表里非常常见比自己在代码里拼两个时间字符串要安全得多至少不会出现时区边界手滑算错的问题。还有两个高频查询值得说。一个是 wildcard它支持通配符匹配比如用*和?但注意它不像 term 那样走倒排索引的精确查找性能开销会随前缀情况变化。很典型的一个案例是在某个后台管理系统的搜索框里用户需要搜订单号片段一开始用 wildcard 前缀模糊搜数据量大了以后明显变慢。后来我们改成 ngram 分词方案把订单号切分成多个短 token用 match 查询替代速度提升了好几个量级。另一个是 exists它用来判断某个字段是否存在比如查所有没有手机号的用户GET /users/_search { query: { bool: { must_not: [ { exists: { field: phone } } ] } } }exists 的语义是字段有非空值才返回空字符串和空数组不会被统计为存在这个细节在和业务方对数据时很容易产生分歧建议提前约定清楚。3. 实战场景从日志检索到商品搜索理论语法讲得再多不如直接看几个贴近业务的查询案例。下面三个场景都是我实际处理过的DSL 结构在这里会更有代入感也能更直观地看出不同需求下相同语法的取舍。3.1 日志检索场景的完整查询示例日志系统大概是 ES 用得最广泛的地方。我要查最近一小时某个服务出现 ERROR 级别且包含 connection timeout 的日志并且排除掉健康检查的请求GET /service_logs/_search { query: { bool: { must: [ { match: { message: connection timeout } }, { term: { level: ERROR } } ], must_not: [ { term: { request_path: /healthcheck } } ], filter: [ { range: { timestamp: { gte: now-1h } } } ] } }, sort: [ { timestamp: desc } ], size: 50 }这个查询把核心的 bool、match、term、range 都串起来了。size控制返回条数sort按时间倒序让最新的日志排在前面。实际使用中我还会加一个_source过滤只返回必要字段 _source: [timestamp, level, message, service_name, trace_id]这样可以显著减少网络传输量日志这种大文本类型的字段在检索量大时很占带宽。检索结果如果用于问题排查我通常建议把trace_id带上方便把同一请求链路上的日志串起来。还要提一个排查慢日志的通用思路先看整体响应时间如果慢第一反应是缩小时间范围第二是检查查询有没有把 text 字段放在 term 里第三是看是否需要加 filter 优化缓存。这三点至少能解决我碰到过的绝大部分日志查询性能问题。3.2 业务数据检索中的过滤与排序在商品搜索这种业务场景里过滤和排序往往是并存的。比如用户想搜 无线耳机同时只看在售的、价格在 200 到 500 之间的商品按销量排序GET /products/_search { query: { bool: { must: [ { match: { product_name: 无线耳机 } } ], filter: [ { term: { status: ON_SALE } }, { range: { price: { gte: 200, lte: 500 } } } ] } }, sort: [ { sales_count: desc } ], from: 0, size: 20 }这里的关键在于 filter 中组合了词条匹配和范围过滤既确保状态一定是在售也把价格区间收进来。sort按销量降序前 20 条展示。可能有人会问搜索词 match 在 must 里不是会影响排序吗确实会影响但因为它匹配的是商品名称而 sort 又显式指定了按销量排序所以 ES 会优先按销量排序相关度分数只在销量相同的情况下作为 tie-breaker。如果你想实现优先展示有评价的商品可以把 has_review 放在 should 里配合 boost 参数should: [ { term: { has_review: true } } ]这种写法不强制要求有评价但匹配上的文档会获得更高分数在排序时自然往前靠。这是在不动 sort 主逻辑的前提下对相关性排序做微调的常用手段。3.3 从查询到聚合统计类需求的实现光有查询还不够很多需求最终落在统计上。比如我要统计某一小时内各接口被调用的次数并按调用次数排序GET /access_logs/_search { query: { bool: { filter: [ { range: { timestamp: { gte: now-1h } } } ] } }, aggs: { by_api: { terms: { field: api_path.keyword, size: 20 } } } }这个 terms 聚合的意思是对 api_path.keyword 字段做分组统计返回前 20 个桶。field选择要根据映射来如果 api_path 是 text 且没指定 keyword 子字段聚合会报错提示fielddata 被禁用。如果确实要在 text 字段上聚合可以开启 fielddata但我不建议大规模这么做因为内存开销大。更好的做法是映射时给 text 字段配一个 keyword 子字段。聚合结果里常见的坑是doc_count_error_upper_bound这是 terms 聚合在分布式环境下由于每个分片只返回自己 Top N 导致的统计误差。如果你的业务对精确度要求极高可以考虑把size调得比实际需要大一些减少误差概率但这会增加内存和延迟。折中方案是按需调整不需要精确到离谱的话默认行为通常够用。4. 聚合分析从零到模式化的实践经验聚合是 ES 区别于普通关系型数据库的一大优势但它也最容易写出性能很糟糕的查询。我在几个数据看板项目里积累了不少聚合相关的实例这里挑几个典型说明。4.1 指标聚合最基础的 avg、sum、max、min指标聚合用法最直接就是用 value 对文档集做统计计算。比如算某天订单的平均金额和总金额GET /orders/_search { query: { range: { created_at: { gte: 2024-01-01, lt: 2024-01-02 } } }, aggs: { avg_amount: { avg: { field: pay_amount } }, total_amount: { sum: { field: pay_amount } } } }这种聚合速度很快而且结果很直观。常见的问题是如果你对一个 text 类型的字段做 avg会直接报错因为 ES 要求被聚合的字段必须启用 doc_values 或 fielddata。数值和日期类型默认启用 doc_values所以一般没问题。另外一个细节是聚合请求里可以同时嵌套多个聚合比如在同一个 aggs 下既算平均值也算最大值它们互不干扰在同一个查询响应里分别返回结果。4.2 桶聚合terms、date_histogram、range 实战桶聚合是分组统计的核心。terms 用法上面已经介绍过了。date_histogram 是按时间维度分桶非常常用于趋势分析比如按小时统计请求量GET /access_logs/_search { aggs: { requests_over_time: { date_histogram: { field: timestamp, fixed_interval: 1h } } } }这里有两个参数容易搞混fixed_interval和calendar_interval。简单说fixed_interval 是固定 1 小时、1 天这种毫秒级的固定时间窗适合数据看板calendar_interval 会考虑日历语义比如month能正确处理每月天数的差异适合月度报表。如果你要按自然月统计建议用 calendar_interval。range 桶聚合则是对数值做区间分组比如统计低价品、中价品、高价品的数量GET /products/_search { aggs: { price_ranges: { range: { field: price, ranges: [ { to: 100 }, { from: 100, to: 500 }, { from: 500 } ] } } } }这种聚合写法不复杂但要注意 range 桶的边界值默认是大于等于from且小于to也就是[from, to)的关系。很多新手以为to: 100会包含 100实际上它不包含。这个边界规则和 SQL 的 BETWEEN 不一样跟业务方对齐需求时一定要说明清楚否则统计结果会有微妙偏差。4.3 嵌套聚合与精确计数问题嵌套聚合是当你想在分组的基础上再做一层统计时的选择。比如按商品类目分组再统计每个类目下不同品牌的数量GET /products/_search { aggs: { by_category: { terms: { field: category_id, size: 10 }, aggs: { by_brand: { terms: { field: brand_id, size: 10 } } } } } }嵌套聚合在需要分层下钻分析的场景里非常有用但也要注意层级越多响应越慢。另一个常见的需求是去重计数。比如统计一天内活跃用户数GET /user_events/_search { aggs: { active_users: { cardinality: { field: user_id, precision_threshold: 40000 } } } }cardinality 用的是近似算法precision_threshold控制精度阈值默认 3000。在阈值以内结果精度很高但超过阈值后误差会快速增加。所以如果你的目标是千万级的精确去重cardinality 不一定合适可能需要借助其他方案。我在某数据看板项目里统计 UV 时就吃了这个近似算法的亏用户量刚过阈值时误差达到 5% 左右后来调整了 precision_threshold 并配合按天分桶才把误差压到可接受范围。5. 排障思路与性能调优心得查询语法写得再花哨线上性能扛不住也是白搭。我这里挑几个最常见的问题做成一个速查表并给出我踩过坑之后总结的优化思路。现象常见原因排查建议match 查不到数据分词器拆词后与文档词项不一致用_analyze接口检查分词结果term 查不到 keyword 字段字段实际是 text已分词确认映射改为 keyword 子字段查询结果相关度不理想should 和 must 混用权重失衡优先规范 bool 结构利用 boost深分页时内存暴涨用了大 from size改用 search_after 或 scroll聚合结果有误差terms 聚合 size 过小分片偏差增大 size或放宽精度要求聚合报错 fielddata 禁用对 text 字段直接聚合给 text 加 keyword 子字段再用 keyword 聚合慢查询高发但看不出问题缺少慢日志和查询 profile开启 slowlog用 profile API 定位耗时点5.1 慢查询定位slowlog 与 profile API排查慢查询第一步是确认哪些查询慢。ES 支持搜索慢日志配置可以在索引级别设置阈值超过阈值的查询会记录到日志里PUT /my_logs/_settings { index.search.slowlog.threshold.query.warn: 2s, index.search.slowlog.threshold.query.info: 1s, index.search.slowlog.threshold.fetch.info: 500ms }配置之后慢查询会输出类似:[my_logs][WARN] took[1.2s], took_millis[1200], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[5], source[{query:{...}}]拿到慢查询语句后下一步就是用 profile API 定位具体是哪一段耗时高。比如:GET /my_logs/_search { profile: true, query: { match: { message: timeout } } }返回结果里会有每个查询阶段的耗时分布可以看到是 lucene 的倒排索引查找慢还是 collect 阶段慢或者是 fetch 阶段慢。我遇到过一次典型的案例某个查询本身很快但 fetch 阶段特别慢原因是文档的_source特别大返回 1000 条时网络和解析开销明显。最后通过限制_source字段整体响应时间下降了 60%。5.2 深分页与全量拉取的正确姿势ES 默认的from size分页方式在浅分页时没问题比如每页 20 条翻前几页没什么压力。但一旦 from 值特别大比如 from10000ES 就需要先把前面所有命中文档都取出来排好序再丢掉前 10000 条这在分布式环境下会带来巨大的内存消耗。如果你需要做数据导出或者大规模翻页建议用search_after。它通过上一页最后一个文档的排序值来定位下一页不依赖 from 跳过。一个典型的实现是:GET /orders/_search { query: { match_all: {} }, sort: [ { _id: asc } ], size: 1000 }拿到最后一条结果的 sort 值后下一页查询变成:GET /orders/_search { query: { match_all: {} }, sort: [ { _id: asc } ], size: 1000, search_after: [ 1024 ] }search_after 要求排序字段必须有唯一性否则可能出现漏数据和重复数据。我一般习惯在 sort 里加上_id兜底保证稳定性。scroll 接口也能做全量拉取但它维护的是快照上下文对资源占用较高现在除非是导数据到其他系统否则我很少用 scrollsearch_after 在多数场景下更轻量。5.3 缓存机制filter 为什么快前面多次提到 filter 有缓存优势这里展开讲一下原理。ES 会为经常使用的 filter 条件建立节点级缓存比如term: { status: PAID }只针对不同值的文档集合做位集缓存后续相同过滤条件可以直接复用。这意味着你不需要反复扫描倒排索引或遍历文档。这个特性的实际意义在于把不变的过滤条件和多变的查询条件分离。比如用户搜索时关键词是不断变化的但类目、状态、价格区间这些条件相对稳定。把稳定条件放到 filter 里可以极大提升查询吞吐。我在某商品搜索服务里做过一个粗略测试同样的组合查询全放 must 的时候 QPS 大概在 500 左右把过滤条件挪进 filter 后 QPS 能到 1100 以上而且延迟更稳定。当然filter 缓存也不是无限的ES 默认只缓存最热门的 filter。如果业务里过滤条件组合特别多缓存命中率会下降这时候不要盲目加内存而是合理设计查询模式。比如尽量复用同一套过滤条件或者把高频条件抽出来做独立查询合并。这些都是在真实项目里验证过的做法比单纯调参更有效。5.4 合理规划 mapping 与 refresh 间隔最后一个容易被忽视的调优点在写入侧。索引的 mapping 如果设计不合理比如把所有字段都设成 text那查询和聚合都会很痛苦。此外 refresh_interval 也会影响查询性能。默认的刷新间隔是 1 秒意味着每秒都可能产生新的分段查询时需要合并更多的分段数据对实时性要求不高的报表类索引可以把刷新间隔调大。PUT /report_index/_settings { index.refresh_interval: 30s }这样能显著降低段合并开销。我维护的一个统计看板索引在数据量逐步变大后把刷新间隔从 1 秒调整到 30 秒查询延迟下降了大约 35%而业务方因为数据延迟了 30 秒完全无感。当然如果场景是订单状态实时更新那就不适合这么调。调优永远是取舍不是一味追求某一个指标。6. 常见问题与排查技巧实录这个部分把我在真实项目里遇到过的典型问题和最终排查结果记录下来做成一个快速对照方便你遇到类似问题时直接对照排查。6.1 索引不存在或别名误用现象是查询时报index_not_found_exception。最常见的是环境配置里索引名写错或者用了别名但别名没建好。我碰到过一个比较隐蔽的情况某个同学把别名写的和索引名一样导致删除重建索引时误删数据。建议给索引命名时加上版本或日期后缀比如logs-2024.11.30用别名指向当前使用的索引版本这样查询逻辑不用变维护时也更安全。6.2 字段存在但查询无结果这个尴尬场景很可能来自两个原因一个是字段值确实在文档里但查询时用了类型不匹配的条件另一个是 text 分词导致完全匹配失效。排查方式是用_termvector或者_analyze去看字段实际被分成了什么词项然后调整查询方式。比如:POST /my_index/_analyze { field: message, text: Internal Server Error }返回结果可以看到分词后的 token结合这个再判断 match 查不到的原因就非常直观。实际项目里我们有一次就是靠这个接口发现了某个字段被 lucene 的 standard 分析器拆成了多个单词而后端同学一直拿完整字符串做 term 查询所以始终匹配不上。这算是非常典型的一类问题。6.3 聚合结果为空或缺失部分数据如果你对某个字段做 terms 聚合发现某些明明存在的值没出现在结果里先检查 mapping 是否用了 text 类型。如果字段类型没问题再看size是否太小默认 terms 聚合返回的桶数是 10如果你数据里有超过 10 种状态排后面的桶就看不见了。把 size 调大或者按需回去查精确值即可。此外还要看查询条件本身是否过滤掉了部分数据聚合的作用范围始终受 query 部分约束这个容易理解但也容易忽略。6.4 查询超时与熔断ES 对单次查询有超时和熔断保护。如果查询体特别复杂、带多层嵌套聚合或者命中数据量极大容易触发circuit_breaking_exception。此时可以降低聚合 size、减少嵌套层级、缩小查询时间范围。如果想避免某个查询时间过长可以给 query 加 timeout。不过 timeout 只是让查询在到达时限后返回部分结果不能保证返回数据完整在准确性要求高的场景需谨慎使用。我自己的经验是优先优化查询结构和索引设计而不是依赖 timeout 兜底。6.5 排序结果不稳定的解决办法如果排序字段有大量相同值翻页时可能出现重复或遗漏。解决办法是排序字段后面追加一个_id唯一值作为 tie-breaker。比如:sort: [ { created_at: desc }, { _id: asc } ]这样能确保排序结果稳定。尤其在用 search_after 深分页时必须保证每个文档的排序组合唯一否则翻页数据可能对不上。这一点我在导数据到数据仓库时吃过亏翻到后期有重复记录花了很久才定位到是排序字段撞值导致的。6.6 映射变更的长期维护建议ES 的一个核心特性是映射一旦建立字段类型不能直接修改。如果发现 mapping 设计不合理最常见方案是新建索引并做数据迁移然后用别名切换。这个操作流程建议提前演练避免线上切换时出问题。我在模拟项目 X 里维护过一套脚本把这些迁移步骤固化成自动化流程包括创建新索引、执行 reindex、校验文档数、切换别名、删除旧索引整个过程控制在分钟级别。建议你也把这类操作沉淀成脚本或文档平时不用但要能随时跑起来。结尾我个人在实际操作中的一个体会是ES 查询的很多问题表面上是语法不够熟底层往往是对分词、映射、缓存机制理解不够深。那些看起来厉害的复杂查询本质都是基础组件的组合。所以我的建议是与其背一堆现成 DSL 模板不如花时间把 text、keyword、match、term、bool、filter、聚合这七个核心概念吃透。真到了排查问题的时候你会发现自己能更快地缩小范围、定位原因。另外最后分享一个小技巧每次在项目里遇到一个查询相关的问题无论最终是否解决都把现象、原因、解法记录下来。我当时整理ES 查询实例等记录的初衷就是这样。现在回头看这份笔记帮我在处理线上问题时的效率提升了不止一倍也让我在和业务方对数据口径时更有底气。只要你的 ES 查询需求不止一次这套记录方法大概率也能帮到你。
