1. 一条ES查询语句的背后：先搞懂查询语法在解决什么问题
做了这么多年搜索和日志分析相关的开发，我几乎每天都要跟Elasticsearch打交道。很多刚接触ES的同学会跑来问我："为什么我明明是按文档抄的查询，结果就是不对？为什么match查出来的结果跟我想的不一样？为什么term查不到数据？"
这些问题背后，其实都是同一个根源：没有真正理解ES查询语法的分类逻辑和底层原理。ES的查询语法不是一套简单的"等于某个值"的拼凑，而是一套从"全文检索"到"结构化过滤"再到"聚合分析"的完整体系。如果你把它当成SQL来写，一定会踩坑。
Elasticsearch（简称ES）最核心的查询入口是_search接口。所有查询，无论多复杂，本质上都是向这个接口提交一个JSON结构的query对象。这个对象里的每一个关键字，比如match、term、bool、range、wildcard，都有它自己的适用场景和底层实现逻辑。搞懂这些，你写出来的查询才会既准确又高效。
这篇文章我就从实际使用角度，把这套基础查询语法掰开揉碎讲清楚。不堆概念，直接上请求、上返回结果、上踩坑记录。文章覆盖的内容，从最基础的_search请求结构，到match与term的底层区别，再到bool组合查询、聚合分析、排序分页、模糊匹配，基本把你日常开发里90%会碰到的查询场景都过了一遍。花二十分钟看完，你至少能少走几个月弯路。
2. 从一个最简单的_search请求说起：请求结构决定了查询的边界
先看一个最基础的查询长什么样。假设我有个电商系统的订单索引，名叫orders，里面存了订单号、用户ID、商品名称、订单金额、订单状态、创建时间这些字段。我一条请求查"商品名称包含'手机'的订单"，写法是这样的：
GET /orders/_search { "query": { "match": { "product_name": "手机" } } }你会发现，整个查询用JSON包成了一个query对象，里面再套具体的查询子句。这就是ES查询的基础骨架：query上下文决定"哪些文档能匹配上"。除了query，这个请求里还能放很多其他顶层参数，比如控制返回条数的size、控制跳过的from、控制排序的sort、控制返回字段的_source、以及做聚合的aggs。
我见过不少新手在query里写排序和分页，或者把聚合写在query外面导致语法报错，这是因为没搞清这些参数的分工。一个完整的_search请求，顶层结构应该是这样的：
GET /orders/_search { "query": { ... }, "from": 0, "size": 20, "sort": [ ... ], "_source": [ ... ], "aggs": { ... } }这里的逻辑很简单：query负责筛选文档，from和size负责取哪几页，sort负责排序，_source负责控制返回哪些字段，aggs负责分组统计。每个参数的职责边界很清晰，互不干扰，但可以在一次请求里协同工作。
实际项目中，我通常会用Kibana的Dev Tools来调试这些请求，因为它有语法高亮和格式化提示，还能看到查询耗费的时间。不过无论用什么工具，请求的JSON结构都是一样的。另外提一个很实用的习惯：正式写复杂查询之前，先只写query部分并加一个"size": 0，确认返回的hits.total数量符合预期，再逐步加上sort、aggs这些参数。这样定位问题会快很多，而不是一上来就写一个几百行的JSON，出错了都不知道错在哪。
2.1 查询结果的结构：别只看hits，_score里藏了很多信息
拿到查询结果之后，很多初学者只知道看hits.hits数组里的文档，却忽略了另外两个关键信息：hits.total和_score。
hits.total是符合查询条件的文档总数，它本身也是一个对象，里面有两个字段：value和relation。正常情况relation的值是eq，表示总数精确匹配；但如果数据量特别大且使用了track_total_hits: false，relation会变成gte，表示总数不小于value。我在做大数据量导出功能的时候专门研究过这个，如果不关心总数，把track_total_hits设为false能让查询快不少，因为ES不需要精确统计全部匹配文档了。
再来看_score，这是ES独有的相关度评分。ES会给每个匹配的文档算一个分数，分数越高，排在越前面。这个分数不是拍脑袋算的，而是基于一套名为BM25的算法算出来的，综合考虑了词频（词在文档中出现越多次，分数越高）和逆文档频率（词在整个索引中出现得越少，这个词越有区分度，权重越高）。比如你搜"手机"，一个商品标题里出现了三次"手机"的文档，得分一般会高于只出现一次的文档。
理解了_score，你就理解了为什么全文检索的返回顺序看起来"不讲武德"。它不是按创建时间排的，也不是按价格排的，默认就是按相关度排。如果你只想看最新订单，就手动指定sort，否则ES会一直用_score排序。这一点在做业务查询时特别容易踩坑——好多人查订单列表发现顺序乱了，其实就是没建排序条件。
2.2 顶层参数的优先级：sort、_source、aggs和query怎么配合
用一个实际场景把这些顶层参数串起来：产品经理要一个"已支付订单中，商品名称包含'手机'的订单列表，按订单金额降序，每一页20条，只要订单号和金额两个字段，同时还要统计一下这些订单的均价"。
这个需求一次性就能写完，请求长这样：
GET /orders/_search { "query": { "bool": { "must": [ { "match": { "product_name": "手机" } } ], "filter": [ { "term": { "status": "paid" } } ] } }, "from": 0, "size": 20, "sort": [ { "amount": { "order": "desc" } } ], "_source": ["order_id", "amount"], "aggs": { "avg_amount": { "avg": { "field": "amount" } } } }注意这里我已经用到了bool查询来组合两个条件，其中status精确匹配放在了filter里。关于bool和filter的细节，下一节专门讲。这里你只需要记住：这些顶层参数是平级的，ES会先执行query筛出文档，再走sort排序，再按from/size切页，最后根据_source裁剪返回字段，同时aggs在筛出的文档集合上做聚合。整个流程是流水线式的，任何一个环节的参数缺失，结果都可能偏离你的预期。
3.match和term的本质区别：全文检索与精确匹配背后是分词器在起作用
如果说ES查询语法里只能记住两件事，我一定选match和term的区别。这是最多的坑，也是最基础的知识点。
3.1match是"分词后匹配"，term是"完整值匹配"
match查询走的是全文检索逻辑。什么叫全文检索？就是ES会先把你要查的输入文本做分词，再用分词结果去倒排索引里找。比如你输入match: {"product_name": "华为手机"}，ES会把"华为手机"这串查询文本交给分词器。以默认的standard分词器为例，它会按空格和标点切词，"华为手机"会被切成"华为"和"手机"两个词（如果是中文场景，standard按单个汉字切，这里先以通用分词器为例）。然后ES拿着这两个词去倒排索引里查找，只要文档的product_name字段里包含"华为"或"手机"任何一个词，就能匹配上，并且根据匹配到的词频等算出_score。
而term查询走的是精确匹配逻辑，它不会分词。term: {"status": "paid"}就是用完整的字符串paid去倒排索引里找一个一模一样的词条。如果字段的mapping类型是keyword，这种方式非常高效，类似数据库里的等值查询。
听起来很简单对不对？但问题就出在"分词"上。ES默认会对字符串类型的字段同时建text和keyword两种类型：text类型经过分词器处理，用于全文检索；keyword类型保留完整字符串，用于精确匹配、排序和聚合。如果你在keyword字段上用match查询，或者在text字段上用term查询，结果往往会出乎意料。
3.2 实际案例：为什么term查不到text字段的数据
有个真实案例特别典型。一个商品索引里有个字段product_name，mapping类型是text，里面存了"Apple iPhone 15 Pro Max"。我让同事去查这个商品，他写了term: {"product_name": "Apple iPhone"}，结果返回0条。他跑来问我说索引坏了。
问题不在索引，在于term不会分词。term拿着完整的字符串"Apple iPhone"去倒排索引里匹配词条，可倒排索引里存的是分词后的结果，比如"apple"、"iphone"、"15"、"pro"、"max"这些独立词条，根本不存在"Apple iPhone"这样一个完整词条，自然查不到。
反过来也一样。如果字段是keyword类型，存的是完整字符串"Apple iPhone 15 Pro Max"，你写match: {"product_name": "Apple iPhone"}，ES会把"Apple iPhone"分词成"apple"和"iphone"两个词去匹配，看起来能查到（因为分词后两个词都命中了），但这种"能查到"很容易误导你，它实际执行的是包含查询而不是精确匹配。
所以最重要的原则是：做搜索框的模糊搜索、全文检索，用match；做状态、分类、ID、精确名称的筛选，用term。并且要先通过_mapping接口确认字段是text还是keyword。业务开发里90%的"查询结果不对"问题，追根溯源都是这个。
3.3match_phrase：要求所有词按顺序出现
match还有一个常用变体叫match_phrase，它解决的是"词序和连续性"问题。举个例子，你搜match: {"product_name": "手机 充电器"}，一个文档里只有"充电器"没有"手机"，也能匹配上，因为match是"或"的逻辑。但如果你用match_phrase，ES要求分词后的所有词必须按顺序且彼此相邻地出现在文档里。
match_phrase有一个非常实用的参数叫slop，它表示词与词之间允许隔多少个位置。比如文档是"华为手机原装充电器"，你搜match_phrase: {"product_name": {"query": "手机充电器", "slop": 2}}，因为"手机"和"充电器"中间隔了一个"原装"，slop设为2就能容忍这个间隔，查询就能命中。这个参数在做内容搜索、标题匹配时非常常用，比如搜索"苹果 数据线"时，希望"苹果原装数据线"这种写法能被命中，slop就派上用场了。
4.bool查询：把多个条件组合起来，别忽略must、should、filter的语义差别
真实业务里很少只查一个条件。订单表通常是"状态 + 时间 + 关键字"一起查，商品表通常是"分类 + 品牌 + 价格区间 + 搜索词"一起查。ES提供了bool查询来组合各种子查询，这是日常使用最频繁的查询结构，没有之一。
4.1 三个核心子句的语义：must是必须满足，should是尽量满足，filter是必须满足且不参与评分
bool查询里有几个常用子句，每个的语义必须记清楚：
must：文档必须满足这里的条件，同时参与相关度评分。比如"商品名称必须包含'手机'"。filter：文档必须满足这里的条件，但不参与相关度评分。比如"订单状态必须是paid"。should：文档可以满足也可以不满足，但如果满足，相关度分数会更高。should单独使用时，至少有一个条件被满足文档才会返回；但如果在must或filter存在的情况下，should变成了"加分项"，不强制满足。must_not：文档必须不满足这里的条件。这个好理解，就是排除。
这四种子句可以随意嵌套组合，形成任意复杂的查询逻辑。下面这个例子，几乎涵盖了电商后台订单管理的常用筛选场景：
GET /orders/_search { "query": { "bool": { "must": [ { "match": { "product_name": "手机" } } ], "filter": [ { "term": { "status": "paid" } }, { "range": { "created_at": { "gte": "2024-01-01", "lte": "2024-12-31" } } } ], "must_not": [ { "term": { "is_refunded": true } } ] } } }这个查询的含义是：返回2024年内已支付、未退款、且商品名称包含"手机"的订单。其中"已支付""时间范围""未退款"都是精确过滤条件，放在filter和must_not里；而"手机"是搜索词，放在must里参与评分。
4.2 为什么filter比must快？缓存机制不是玄学
实际开发中，我特别建议把"筛选类"条件放进filter而不是must。原因有两个：
第一，语义上更准确。must的评分会干扰排序。比如你搜索"手机"，某条订单只匹配了一次"手机"，但它的status恰好是paid。如果你把status放进must，ES会在算分时把这个条件的匹配也纳入_score，会导致"卖了一百单的老客户订单"排到某些只匹配了两个词的新订单前面，排序逻辑就乱了。放进filter就完全没这个问题，它的分数只由must里的搜索条件决定。
第二，性能上有缓存优势。ES对filter条件有专门的缓存机制，同一个filter条件在短时间内重复查询时，可以直接复用之前的结果集，省去重新扫描倒排索引的消耗。把高频筛选条件（比如status: paid、created_at区间）放进filter，在对高并发查询的优化效果上非常明显。
我记得有一个日志查询系统，最开始把所有条件都写在must里，高峰期查询耗时平均在800ms左右。后来把时间范围、日志级别这些过滤条件全部挪到filter，查询耗时降到了200ms以内。这就是filter缓存带来的实际收益，不是玄学。
4.3should的两种行为模式，很多人第一反应是错的
should是bool查询里最容易出认知偏差的子句。我特意把这个单独拎出来讲。
should的行为取决于bool查询里还有没有其他强制性子句：
- 场景一：
bool里只有should。这时它的语义等同于"OR"，即至少满足一个条件才会返回文档。 - 场景二：
bool里既有must又有should。这时should退化为"加分项"，不满足should的文档也会返回，只是分数比满足的低。
举一个业务例子帮助理解。电商搜索里常见的需求是：搜索"手机"，希望标题匹配的排在前面，同时"品牌是华为"的也排在前面。这个需求的逻辑应该写成：
GET /products/_search { "query": { "bool": { "must": [ { "match": { "product_name": "手机" } } ], "should": [ { "term": { "brand": "华为" } } ] } } }这样写，所有标题包含"手机"的商品都会返回，但品牌是华为的商品会在排序上获得额外加分、排到更前面。这种"加权"效果是should最常见的用法。
4.4 用minimum_should_match控制should的最低命中数
再往后走一步。当你在一个bool查询里写了多个should条件，希望至少命中其中两个文档才返回，就要用到minimum_should_match参数。
比如说搜索酒店，用户希望"靠近地铁站"或"含早餐"或"免费取消"至少满足两个，可以这样写：
GET /hotels/_search { "query": { "bool": { "should": [ { "term": { "near_subway": true } }, { "term": { "breakfast_included": true } }, { "term": { "free_cancel": true } } ], "minimum_should_match": 2 } } }这个参数在搜"复合标签"的场景中很常见。比如文章系统里给文章打标签，用户筛选带有"Java""并发""性能优化"三个标签的文章，要求至少命中两个，minimum_should_match: 2直接搞定。它的值可以是数字、百分比，甚至是一个复杂的表达式。日常开发用数字就够，百分比适合动态控制灵活度的场景。
5. 聚合查询：当size: 0成为习惯，aggs能帮你做报表分析
ES最让我惊艳的能力不是搜索，而是聚合分析。刚用ES做日志统计的时候，我一度以为要先把数据查出来再在代码里慢慢算，后来发现一条aggs请求就把报表搞定了，性能还高得离谱。
5.1 先跑通一个最简单的terms分组统计
先看一个最基础的聚合需求：统计订单索引里每种状态的订单数量。这个需求在SQL里是SELECT status, COUNT(*) FROM orders GROUP BY status，在ES里长这样：
GET /orders/_search { "size": 0, "aggs": { "group_by_status": { "terms": { "field": "status", "size": 10 } } } }返回结果里会多出一个aggregations节点，里面有一个名为group_by_status的聚合结果，每个桶包含key（比如paid）和doc_count（比如1024）。这里有两个细节要注意：
第一，"size": 0意味着不返回具体文档，只返回聚合结果。如果你只是做统计报表，这个参数能省掉大量网络传输开销。很多人在写聚合时忘记加size: 0，白白把成千上万条文档从ES拉到应用层，再被程序丢掉，非常浪费。
第二，terms聚合的field必须是keyword类型，或者开启了fielddata的text类型。ES默认不允许在text字段上直接做聚合，因为text字段经过分词后，每个词都是一个独立的词条，直接聚合出来的是一堆零碎词频，几乎没有业务意义。如果你非要在text字段上聚合，mapping里需要显式开启fielddata: true，但我不建议这样做，它会吃掉大量堆内存。正确做法是在mapping里给这个字段额外建一个keyword子字段，比如product_name.keyword，然后在聚合时用product_name.keyword。
5.2avg、sum、max、min：指标聚合的基础用法
terms属于桶聚合（Bucketing），分组后每一组是一个桶。除了桶聚合，还有指标聚合（Metric），用来计算值。继续用订单表举例，统计已支付订单的平均金额、总金额、最大单笔金额，一条请求写完：
GET /orders/_search { "query": { "bool": { "filter": [ { "term": { "status": "paid" } } ] } }, "size": 0, "aggs": { "avg_amount": { "avg": { "field": "amount" } }, "sum_amount": { "sum": { "field": "amount" } }, "max_amount": { "max": { "field": "amount" } }, "min_amount": { "min": { "field": "amount" } } } }一次性在aggs里声明多个聚合，它们会并行执行，互不干扰。这里注意，amount字段必须是数值类型，如果是字符串就没办法做这种数值计算了。这也是为什么建索引之前一定要设计好mapping，字段类型一旦定错，后面查询和聚合全都会出问题。
聚合还有个大杀器叫子聚合，就是在桶聚合的结果里再套一层聚合。比如统计每个商品分类下的平均价格和最高价格：
GET /products/_search { "size": 0, "aggs": { "by_category": { "terms": { "field": "category.keyword" }, "aggs": { "avg_price": { "avg": { "field": "price" } }, "max_price": { "max": { "field": "price" } } } } } }这样返回的每个分类桶里，都会带上avg_price和max_price两个指标。这种"先分组，再对每组做统计"的嵌套结构，是ES聚合最强大的地方。它可以把SQL里需要多次GROUP BY才能完成的复杂报表，压缩成一条请求。我在做商品运营报表时，经常用这类查询从几千万的商品数据里直接拉出各分类的销售统计。
5.3 聚合中的filter和range：让分组统计更精细
有时候你要在聚合之前先过滤一部分数据。举个例子，统计2024年每个月份的订单数。这里用到的不是前面介绍的range查询，而是聚合里的date_range桶聚合，或者更常用、更灵活的filter聚合。
先看一个filter聚合的典型用法：统计已支付订单的金额和未支付订单的金额。
GET /orders/_search { "size": 0, "aggs": { "paid_orders": { "filter": { "term": { "status": "paid" } }, "aggs": { "total_amount": { "sum": { "field": "amount" } } } }, "unpaid_orders": { "filter": { "term": { "status": "unpaid" } }, "aggs": { "total_amount": { "sum": { "field": "amount" } } } } } }这个查询返回两个桶，一个只包含已支付订单并在其中计算总金额，另一个只包含未支付订单并计算总金额。filter聚合的作用就是在聚合子层级上做条件过滤，不影响整体的query结果集。这种写法在做各种对比报表时非常方便，你想按什么维度切分统计，就写几个filter聚合桶。
另外，date_histogram是时间序列统计的神器，按天、按月、按年自动分桶。我拿它做系统监控指标（如每分钟的请求数、平均响应时间）相当顺手。一段典型用法：
GET /logs/_search { "size": 0, "aggs": { "requests_per_minute": { "date_histogram": { "field": "@timestamp", "fixed_interval": "1m" } } } }它会按分钟把日志切成一堆桶，每个桶的doc_count就是这一分钟的请求量。如果再加一个avg子聚合去算每分钟的平均响应时间，一个简易的监控仪表盘数据就齐了。
6. 查询结果的处理：排序、分页、字段裁剪，这些细节决定体验
很多ES初学者能写出match查询，但一到"排序怎么不对""分页怎么越翻越慢""返回字段太多了怎么办"这些问题就卡壳。这一节把这些"查询之外的细节"讲透，因为它们是决定一个查询能否真正落地到业务系统的关键。
6.1 排序的坑：text字段默认不能排序，为什么？
先说一个最常见的报错：对product_name排序，ES直接抛异常。原因很简单，text字段经过分词后，存进倒排索引的是一个个独立的词条，而不是完整的原始字符串。你可以想象，一个字段被拆成了"苹果"、"手机"、"手机壳"这些词，按它们排出来的顺序毫无意义。因此ES默认不允许在text字段上排序。
解决办法有两个方向：
- 对
keyword字段排序。如果mapping里已经给product_name建了keyword子字段，用product_name.keyword排序即可。 - 如果确实需要按某种自定义规则排序，可以单独建一个排名字段维护。
排序的JSON写法是这样：
GET /orders/_search { "query": { "match_all": {} }, "sort": [ { "amount": { "order": "desc" } }, { "created_at": { "order": "asc" } } ] }多个排序条件按先后顺序生效：先按金额降序，金额相同的再按创建时间升序。要注意的是，一旦指定了sort，返回结果里的_score就不再有排序意义，因为它默认就退出了排序流程。如果你希望"既要相关度排序，又要某个字段作为次级排序"，可以把_score显式写在sort数组里，比如{ "_score": { "order": "desc" } }。
6.2 分页的两种方案：from/size适合浅分页，search_after适合深分页
ES的分页非常简单：
GET /orders/_search { "query": { "match_all": {} }, "from": 0, "size": 20 }from表示跳过多少条，size表示返回多少条。第一页是from: 0，第二页是from: 20，第三页from: 40，以此类推。这跟MySQL的LIMIT 20, 20是同一个逻辑。
但这里有个巨大的性能陷阱：深分页。ES分布式架构决定了它的分页不是单纯"跳过多少条"那么简单。当请求翻到第100页（from: 1980, size: 20）时，ES实际上需要从每个分片里取出前2000条数据，汇聚到协调节点后排序，再截取第1980到2000条。这意味着页面越深，内存和CPU开销越大。我曾经在数据量过亿的索引上翻到第50页，单次查询耗时从30ms飙升到了4秒多，导致线上接口直接超时。
结论是：from/size只适合深度在1万以内的分页。如果用户需要翻得很深，或者要支持"无限滚动"（比如App下拉加载），正确方案是search_after。它的思路是用上一页最后一条文档的排序字段值，作为下一页的起点。实现方式是：拿到上一页最后一条数据的排序值，在下一页请求里把这个值传给search_after：
GET /orders/_search { "query": { "match_all": {} }, "sort": [ { "order_id": "desc" } ], "size": 20, "search_after": [1092837465] }这里order_id是唯一且有序的字段。下一页请求时，search_after填的是上一页最后一条的order_id值。ES会直接从那条数据之后开始取，不会再从头扫描。它的代价是：不能跳页，只能一页一页往下翻。但绝大多数"加载更多"场景恰恰不需要跳页，所以search_after是生产环境里的主流方案。
6.3_source字段裁剪：控制返回字段，减少网络开销
当查询结果只需要几个字段时，用_source裁剪返回内容，能显著减少网络传输和内存占用。
GET /orders/_search { "query": { "match_all": {} }, "_source": ["order_id", "amount", "status"] }这条查询只返回订单号、金额、状态三个字段，其他字段一概不传。这在API网关、移动端接口等带宽敏感的场景下很有用。还可以用通配符，比如"account_*"返回所有以account_开头的字段。不过要注意，_source只影响返回结果，不影响查询匹配逻辑。就算你不返回某个字段，它依然可以被查询和排序使用。
7. 模糊与通配查询：wildcard、regexp、query_string，这些"高级查询"用的时候要想清楚
总有人问我："ES能不能像数据库里的LIKE '%手机%'一样模糊查？"答案是可以，但代价要想清楚。ES里有wildcard、regexp、fuzzy、query_string等一堆"看起来很方便"的查询，用不好就是性能杀手。
7.1wildcard通配符查询：能做模糊匹配，但别在超大数据集上裸用
wildcard查询支持*（匹配任意字符序列）和?（匹配单个字符），比如：
GET /products/_search { "query": { "wildcard": { "product_name.keyword": { "value": "苹果*" } } } }这个查询会匹配所有product_name以"苹果"开头的文档，类似SQL里的LIKE '苹果%'。听起来很方便对吧？但它有个严重问题：如果value以*或?开头，比如*手机*，ES无法利用倒排索引快速定位，只能全表扫描。想象一下，你在一个几千万条的索引里做这种查询，每一个文档都要被遍历一遍，性能灾难几乎是注定的。我在日志系统里排查过一次线上故障，某条业务查询就是写了"value": "*error*"，直接把ES节点的CPU打满了。
如果必须做包含式的模糊匹配，业界通用的做法是引入ngram分词器，把"手机"拆成"手"、"手机"、"机"这样的n-gram词条，存入索引，然后用match查询去命中。这样倒排索引还能派上用场，性能比wildcard高几个数量级。但ngram会增加索引体积，属于典型用空间换时间的方案，需要跟产品确认是否值得。
7.2regexp正则查询：灵活但更危险
regexp允许使用正则表达式匹配字段值，比wildcard更强大。比如查所有型号包含"iPhone 1"且后缀是一个数字的商品：
GET /products/_search { "query": { "regexp": { "product_name.keyword": "iPhone 1[0-9]" } } }但regexp同样面临正则性能问题，尤其当正则表达式包含复杂的回溯匹配时，CPU消耗非常夸张。我的原则是：生产环境尽量不用。如果需要正则，优先在查询前先在应用层把候选集缩小，再对缩小后的数据做正则过滤。其实很多业务场景里的"正则需求"，用prefix+range组合就能覆盖大半。
7.3query_string：一个字符串写出复杂查询，但别直接暴露给用户
query_string是一个非常特殊的查询，它允许用类似Lucene查询语法的字符串来表达复杂逻辑。比如：
GET /products/_search { "query": { "query_string": { "query": "product_name:手机 AND price:[1000 TO 5000]" } } }这条查询等价于"商品名称包含手机且价格在1000到5000之间"。query_string非常强大，支持AND、OR、NOT、通配符、正则、范围等多种语法，但它也是安全风险最高的查询。如果你把用户输入的搜索词直接拼进query_string，用户只要输入一个*或者精心构造的特殊字符，就可能把你整个索引的内容拉出来，甚至导致查询超时。我在接第三方系统时见过他们把前端搜索框的输入直接透传到query_string，结果一个空字符串查询就把集群打挂了。
所以我的建议是：query_string可以在Kibana调试时用，但产品化接口里尽量用显式的bool+match+term组合，不要直接把用户输入喂给query_string。如果你非要用，至少加一层字符白名单过滤，去掉*、?、/等特殊字符，并让输入超时自动中断。
7.4prefix前缀查询：适合输入提示和自动补全的轻量场景
prefix用来查某个字段以指定前缀开头的文档，比如搜索框自动补全，用户输入"苹"，下拉框展示"苹果""苹果手机""苹果数据线"：
GET /products/_search { "query": { "prefix": { "product_name.keyword": "苹" } } }prefix比wildcard效率高一些，因为它能利用倒排索引中的词项顺序快速定位到前缀位置，但也别指望它能媲美match。真正大规模的自动补全场景，我一般会用completionsuggest这种专门设计的功能，或者直接走ngram+match方案。prefix最多只能算"小规模数据时的轻量方案"。
8. 一段完整的实战代码：把前面的语法串起来做商品筛选
前面每块语法都是拆开讲的，最后我来演示一个真实业务场景，把match、bool、sort、aggs、_source全部串起来。假设要做一个电商后台的商品筛选页面，筛选条件有：搜索关键词"手机"、品牌是"华为"或"小米"、价格在1000到5000元、库存大于0，按价格升序排列，每页20条，同时统计结果总数和价格区间分布。
GET /products/_search { "query": { "bool": { "must": [ { "match": { "product_name": "手机" } } ], "filter": [ { "terms": { "brand.keyword": ["华为", "小米"] } }, { "range": { "price": { "gte": 1000, "lte": 5000 } } }, { "range": { "stock": { "gt": 0 } } } ] } }, "from": 0, "size": 20, "sort": [ { "price": { "order": "asc" } } ], "_source": ["product_id", "product_name", "brand", "price", "stock"], "aggs": { "price_ranges": { "range": { "field": "price", "ranges": [ { "to": 2000 }, { "from": 2000, "to": 3500 }, { "from": 3500 } ] } } } }这个请求的意图很清楚：must里的match负责"手机"的相关度筛选，filter里的terms、range负责品牌、价格、库存的精确条件过滤，sort按价格排序，_source裁剪返回字段，aggs算了三个价格区间的商品数量，方便前端展示分布直方图。
你可能会想，为什么不用should来实现"华为或小米"？因为should是"尽量满足"的语义，放这里会导致"品牌不是华为也不是小米"的文档也有可能返回。正确写法是用terms查询，它专门用于"字段值属于某个集合"的场景，语义精确，性能也好。terms是term的多值版，只要是精确匹配、多个值取其中一个，就优先用它。
我还想强调一点：写这种组合查询时，建议先在Dev Tools里把query部分单独跑一遍，确认返回的total数正确，再逐步加上sort、aggs。如果最终的结果和预期不一致，回查时先确认字段类型、再确认分词行为，基本能把问题范围缩小到很小的区域。
9. 版本差异和踩坑记录：ES 5.x、7.x到8.x的API变化，以及几个我至今记得的教训
ES版本演进很快，不同版本之间查询语法有差异。我最早用的是ES 5.x，后来升级到7.x，再到现在项目基本都在8.x。这里分享几个真实的版本变化和踩坑记录，希望能帮你少走弯路。
9.1 从_type消失到7.x的兼容性变化
ES 5.x时代，索引下还能分_type，查询时要带上type。到6.x开始_type被弱化，同一索引默认只能有一个type，7.x直接移除了_type。如果你在网上翻到老教程，写了GET /orders/orders/_search这种带type的路径，在新版本里直接会报错。正确写法是GET /orders/_search。我在一次接第三方数据同步项目时，对方的代码还是5.x风格，到处是type路径，升级后全部要改，费了很大劲。现在做新项目，直接上8.x，查询路径一律不带type。
9.2size: 0与track_total_hits的控制
7.x开始，ES出于性能考虑，默认在size: 0的聚合查询中只精确返回不超过10000条的总数。如果你查询的数据量超过1万，hits.total.value返回的可能是10000，但relation字段会变成gte，表示真实总数不低于10000。这在做分页和报表统计时要特别注意。
如果业务上必须获得精确总数，在请求里加上：
"track_total_hits": true这样ES会完整统计匹配总数，但代价是查询变慢。如果你的场景根本不关心总数（比如无限滚动加载），可以显式设置"track_total_hits": false，ES就不算总数了，性能还能再快一点。我做日志查询时，用户根本不看"共多少条"，这时候关掉总数统计，查询响应速度会有明显提升。
9.3keyword字段的normalizer：精确匹配前的"整理"
再分享一个很多人不知道的小细节。keyword字段默认区分大小写，存进去是"Apple"，用term: {"brand.keyword": "apple"}就查不到。如果你的业务希望查询时忽略大小写，可以在mapping里给keyword字段配置normalizer：
{ "mappings": { "properties": { "brand": { "type": "keyword", "normalizer": "lowercase_normalizer" } } }, "settings": { "analysis": { "normalizer": { "lowercase_normalizer": { "type": "custom", "filter": ["lowercase"] } } } } }配置了normalizer后，ES在索引时和查询时都会先把值转成小写再比较，term: {"brand": "apple"}就能匹配到"Apple"了。这个细节在做用户输入容错、品牌名归一化时特别有用。
9.4 三个让我记忆深刻的查询性能事故
第一起事故是生产环境一个商品搜索接口，用户输入一个没有加引号的搜索词，走了match查询，结果返回了十几万条数据，接口超时。后来发现是搜索词太短（只有"机"一个字），分词后匹配到了大量文档。match查询天然是"包含即匹配"，对于通用词、短词要额外考虑结果集大小和评分排序。
第二起事故是日志系统里有人在filter里写了一个正则，匹配整个日志文本字段，ES节点CPU直接100%。排查了很久才发现是正则回溯导致的计算爆炸。凡是涉及正则的查询，都要做性能测试，并且严格控制输入长度。
第三起事故是一个数据同步任务，明明索引里更新了数据，查询结果却还是旧的。排查到最后发现是ES的近实时性问题：ES默认refresh_interval是1秒，写入的数据要等下一次refresh才能被搜索到。如果你的业务要"写入后立即能查到"，可以调小refresh_interval，但代价是写入性能下降。这个平衡要根据业务场景自己拿捏。
10. 从基础语法到工程化方案：给刚入门ES的开发者几条我亲身验证过的路线
前面语法讲了不少，最后想从工程实践角度，给刚入门ES查询的开发几条我踩过坑之后验证过的建议。
第一，建mapping之前，先想清楚每一个字段的类型。这是ES项目里最重要、也最容易忽略的一步。你决定product_name用text还是keyword，直接决定了后面能不能排序、能不能聚合、模糊查询怎么走。如果mapping建错了，最好的办法是在数据量还小的时候重建索引，拖到几千万条数据再改就非常被动了。
第二，写任何查询之前，先跑一个_mapping看看字段类型。这只需要几秒钟，但能避免你写出一堆"看起来对但实际查不到"的查询。我发现很多ES问题不是语法不会写，而是对字段类型和分词行为不了解。term查text字段查不到这个问题，我至少帮同事排查过几十次。
第三，生产环境避免使用query_string、wildcard、regexp这类"高自由度"查询。不是它们不能用，而是用它们之前必须做充分的性能评估和输入约束。搜索框的输入直接透传到这类查询里，是导致ES集群被打挂的常见原因。能用bool加match/term表达的需求，就不要去碰"看起来很优雅"的字符串语法。
第四，学会用Kibana的Dev Tools和_search的profileAPI。profile能告诉你一次查询的每一个子句花了多少毫秒数、命中了多少文档，这对性能定位帮助巨大。我以前排查慢查询，靠经验猜半天，后来学会了看profile输出，问题原因一眼就能看出来。这个工具的价值，比很多付费的ES监控插件都高。
第五，把常见的查询封装成模板或者工具方法。比如我平时会封装一个BoolQueryBuilder的构建器，把must、filter、should、sort、分页这些参数通过Java或Python的API传进去，返回一个完整的请求体。这样业务同学只需要关心业务参数，不用每次手写JSON，也不容易出错。ES官方客户端（Java、Python、Go）都提供了对应的Builder模式，建议优先使用，而不是自己手工拼JSON字符串。
ES的查询语法体系很庞大，但这篇文章覆盖的内容，已经足够支撑你完成日常95%的业务查询需求。剩下那5%，等你真的遇到了，再带着具体问题去查官方文档，效果会比一开始就啃文档好得多。实际操作中多跑几次Dev Tools、多看一眼返回里的_score和took字段，你对ES查询的理解会越来越扎实。
