Elasticsearch在Java后端项目里基本已经成了标配，搜索引擎、日志平台、推荐召回、商品筛选，几乎每个业务线都能找到它的身影。但凡是动手写过ES接口的人，大概率都经历过同一个阶段：看着官方文档里琳琅满目的API和两百多个方法，完全不知道从哪下手。这篇东西不打算重新讲一遍倒排索引原理，那些网上到处都是，我直接结合自己这几年用Java操作ES的实战经验，把索引管理、文档读写、查询聚合、批量优化以及几个特别容易踩的坑全部串一遍，适合那些已经知道ES是什么、但还没系统梳理过API用法，或者正在项目里被各种客户端和查询写法折磨的人。
1. 客户端选型：同一个ES，三种连接方式差距有多大
先解决一个很多人纠结的问题：Java操作ES到底该用哪个客户端。这个问题几乎每次做技术评审都会讨论一轮，我的建议一向很明确：在2024年的今天，别再用TransportClient，也别折腾旧版RestHighLevelClient，直接用官方最新版Java Client，或者退一步用兼容层，前提是你得搞清楚它们之间的本质区别。
1.1 TransportClient为什么活该被淘汰
早期做ES开发时用的TransportClient，走的是TCP二进制协议，端口默认9300。那会儿它确实是性能最好的方案，因为不需要经过HTTP层，请求序列化开销小。但它的致命伤在于必须跟服务端保持版本完全一致，比如集群是7.1，客户端就得是7.1，小版本都不能差太多，否则序列化协议一变动，连接直接失败。更麻烦的是，它把ES内部的节点发现、分片路由逻辑全塞进了客户端，等于每个业务应用都内置了一个迷你ES集群节点，元数据同步、网络嗅探一堆事，生产环境稍微复杂一点就会出幺蛾子。官方在7.0就把TransportClient标记为废弃，8.0彻底移除，现在加入新项目如果还有人提这个方案，可以直接一票否决。
1.2 RestHighLevelClient和官方新客户端的取舍
RestHighLevelClient是ES 7.x时代的主流选择，走HTTP接口，对版本要求宽松得多，主要版本兼容就好。它在7.x版本里功能覆盖非常完整，索引CRUD、查询、聚合、异步操作都能做。但它有个尴尬的身份：高层API建立在低层RestClient之上，而官方在8.0之后推出了全新的Java Client，基于ElasticsearchClient构建，API设计完全重写，更贴近Elasticsearch新的风格，同时把之前散落的各类请求对象统一成了带Builder的写法。新客户端还支持响应式编程模型，可以用异步Reactive方式处理结果，这点在高并发场景下区别很明显。
1.3 我的选型结论与Spring Boot集成
我自己在8.x集群上直接用官方Java Client，因为API干净、官方持续维护、未来升级路径清晰。如果你项目还在7.x，那就用RestHighLevelClient，稳定而且资料多。但不管哪种，建议都用Spring Boot的自动配置接入。回顾我最近的一个搜索服务项目，用Spring Boot 2.7集成ES 7.15，配置只需要注入一个RestHighLevelClient Bean即可，整个项目代码里不需要手动管连接生命周期。版本切到8.2之后，我换成了官方Java Client并依赖Spring的配置管理，代码改动集中在查询构建层，整体平滑过渡。选型的关键不是谁的API潮，而是你的集群版本和团队维护能力，能用最少代码稳定运行才是最优先的。
2. 环境准备与连接初始化：这几个参数默认值会坑人
很多人第一周调ES接口，性能问题不是出在查询语句上，而是连接初始化就没配好。ES客户端默认的HTTP连接管理极其保守，不调参数的话并发稍微上来就会排队超时。
2.1 Maven依赖版本必须跟集群强匹配
依赖这块，ES官方就一句话：客户端主版本号必须和集群主版本号一致。我见过一个真实案例，有人用7.17的客户端连7.10的集群，表面上增删改查都正常，但只要一调用新版本才有的API，直接反序列化报错。所以第一步去Maven仓库把版本锁定好。7.x对应的高层依赖长这样：
<dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-high-level-client</artifactId> <version>7.15.2</version> </dependency>8.x官方Java Client的依赖变成：
<dependency> <groupId>co.elastic.clients</groupId> <artifactId>elasticsearch-java</artifactId> <version>8.11.1</version> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.15.2</version> </dependency>注意到8.x的客户端需要额外引入Jackson做JSON序列化，它是通过JacksonMapper把Java对象转成ES请求的。如果项目里已有Jackson依赖，版本尽量对齐，避免出现类加载冲突。
2.2 连接池和超时参数怎么调才靠谱
RestHighLevelClient底层用的是Apache HttpClient，连接池默认参数非常保守：每个路由最大连接数只有20，连接请求超时只有-1（无限等）。我曾经在一个日志分析服务上看到过，QPS到300左右就开始大量超时，排查到最后发现堆栈全部堵在连接池获取连接的pending队列里，问题就出在这参数上。
构建客户端时务必把连接池和超时给足：
HttpClientConfigCallback callback = builder -> { builder.setMaxConnTotal(200); builder.setMaxConnPerRoute(100); builder.setConnectionManagerShared(true); builder.setDefaultRequestConfig(RequestConfig.custom() .setConnectTimeout(5000) .setSocketTimeout(60000) .setConnectionRequestTimeout(5000) .build()); return builder; }; RestHighLevelClient client = new RestHighLevelClient( RestClient.builder(new HttpHost("10.0.0.10", 9200, "http")) .setHttpClientConfigCallback(callback) .setRequestConfigCallback(req -> req .setConnectTimeout(5000) .setSocketTimeout(60000) .setConnectionRequestTimeout(5000)) );这里有一个容易被忽视的点：setSocketTimeout必须大于等于ES端搜索超时时间。默认ES搜索超时是30秒，socketTimeout如果设成30秒，刚好卡在边界上，大查询一超过30秒就直接客户端超时，但ES服务端还在继续执行。这类问题在监控上看起来是客户端报错，实际瓶颈在服务端，排查时特别迷惑。
2.3 优雅关闭和重建连接的正确方式
客户端是重量级对象，每个应用只初始化一次，别在每次请求时都new一个。我之前见过有人把RestHighLevelClient的构建写在Service方法里，每次查询都新建连接，最终导致系统文件句柄爆满。正确的做法是交给Spring容器管理，用@Bean生成单例，应用关闭时调用client.close()或者交给@PreDestroy释放。8.x的ElasticsearchClient同理，传输层Transport保持单例，底层复用连接。如果你做的是非Spring的纯Java应用，也要在启动时初始化、进程退出时关闭，别偷懒。
3. 核心API实战：索引、文档、批量写入的高频写法
基础API没什么玄学，但有几个写法细节决定了代码是优雅还是难看。先从索引设计说起。
3.1 创建索引与Mapping设计
ES的Mapping定义了字段的分析方式，这里的每一个决策都会直接影响查询语义。我建议索引建好就别频繁改Mapping，改字段类型几乎等于重建索引。所以建索引时宁可多花点时间设计，也不要上线后反复调整。
用Java API创建索引并带一个keyword+text双字段的典型配置：
CreateIndexRequest request = new CreateIndexRequest("product"); request.settings(Settings.builder() .put("index.number_of_shards", 3) .put("index.number_of_replicas", 1) .put("index.refresh_interval", "10s") ); request.mapping(""" { "properties": { "name": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "price": { "type": "double" }, "categoryId": { "type": "keyword" }, "stock": { "type": "integer" }, "createdAt": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss||strict_date_optional_time" } } } """); client.indices().create(request, RequestOptions.DONE);几个关键点：价格字段用double没问题，但如果涉及金额交易，建议换算成long的“分”存储，避免浮点误差。日期字段一定把format显式写出来，否则ES默认用严格ISO格式，你存一个"2024-05-20 10:30:00"直接报格式错误。categoryId这种精确匹配字段用keyword，粒径大的长文本用text。
3.2 单文档增删改查的高频姿势
单文档操作核心是index、get、update、delete，这四个方法在RestHighLevelClient里同名。但有几个细节别忽略。
index请求最重要的判断是：到底该用index还是update？index每次都会覆盖整个文档，版本号+1，如果只是要更新其中两个字段，update请求的开销小很多。实现示例如下：
// 新增或全量覆盖 IndexRequest indexRequest = new IndexRequest("product") .id("1001") .source(Map.of("name", "蓝牙耳机", "price", 299.0), XContentType.JSON); client.index(indexRequest, RequestOptions.DONE); // 局部更新 UpdateRequest updateRequest = new UpdateRequest("product", "1001") .doc(Map.of("stock", 99)) .retryOnConflict(3); client.update(updateRequest, RequestOptions.DONE);retryOnConflict是很容易被忽略的参数。ES更新文档采用的是乐观锁机制，每次更新都检查版本号，并发场景下如果两个线程同时基于旧版本更新，后提交的那个会收到版本冲突异常。retryOnConflict的意思不是重试整个操作，而是重新读取最新版并再次尝试更新，对高并发库存扣减这类操作很有用。但如果更新逻辑依赖旧值做计算（比如库存扣减），重试解决不了问题，这种情况应该改用脚本更新或者用版本号做条件更新，下面的问题和排障章节会细说。
3.3 Bulk批量写入：吞吐提升的大杀器
批量写入不是简单地在循环里调用index，而是把所有操作打包成一个BulkRequest，一次HTTP请求发给ES。这么做有几个好处：减少网络RTT、减少请求解析开销、让ES分片并行处理。实测小批量500条一批，吞吐量能比单条写入高一到两个数量级。
标准写法：
BulkRequest bulkRequest = new BulkRequest(); for (Product p : productList) { bulkRequest.add(new IndexRequest("product") .id(p.getId()) .source(Map.of(...), XContentType.JSON)); } BulkResponse response = client.bulk(bulkRequest, RequestOptions.DONE); if (response.hasFailures()) { for (BulkItemResponse item : response) { if (item.isFailed()) { log.error("写入失败, id={}, error={}", item.getId(), item.getFailureMessage()); } } }批量大小怎么选？有人喜欢一次提交几万条，觉得这样吞吐最高，但实际会出问题。批量请求太大时ES需要把整个请求放进内存解析，大批量很容易触发内存压力甚至OOM。我的经验是单批控制在1000到3000条之间，数据量大时用线程池并发提交多个批次，每个批之间稍微错开，比单批海量数据稳定得多。另外一个关键点，BulkRequest里有失败项并不会抛异常，返回的BulkResponse的hasFailures()才是判断依据。初用者经常忽略这一点，失败数据的报警都没配，业务出了数据问题人还蒙着。
4. 查询API深度拆解：别让一条查询拖垮整个集群
如果说前面的CRUD是热身，查询才是真正体现功力的环节。ES的查询DSL在Java API里是一堆Builder的拼装，核心就三类：叶子查询、复合查询、聚合。
4.1 term与match：搞不清这俩，查询结果必然千奇百怪
排查线上查询问题的时候，我见过最多的一类错误就是用queryString或者match去查一个keyword字段，查出来结果跟你预期完全不一样。这就要回到分词机制上。
match查询会把你的查询关键字做分词处理，再对分词后的词项作文档匹配。比如查“蓝牙耳机”，match会拆成“蓝牙”和“耳机”，然后查包含这两个词中任意一个的文档。term查询则不加任何处理，直接拿整个“蓝牙耳机”去精确匹配某个词项。对keyword字段，ES存储的是一个完整的不可分词的词项，所以要用term查。对text字段，存储的是分词后的多个词项，你用term查一个完整短语大概率查不到任何东西，或者精准命中率极低。
QueryBuilder termQuery = QueryBuilders.termQuery("categoryId", "10023"); QueryBuilder matchQuery = QueryBuilders.matchQuery("name", "蓝牙耳机"); QueryBuilder multiMatchQuery = QueryBuilders.multiMatchQuery("蓝牙耳机", "name", "description");一个更微妙的坑在match的operator参数上。默认match是OR逻辑，拆分的词项中只要有一个命中就算匹配，这对某些业务来说是灾难。做商品搜索时，用户输入“蓝牙 耳机”原意是过滤出既包含蓝牙又包含耳机的商品，结果默认行为把只含“蓝牙”的设备也捞出来。解决办法是显式指定：
QueryBuilders.matchQuery("name", "蓝牙 耳机").operator(Operator.AND);另外，如果你追求的是搜索引擎那种“切词后按相关度排序”，matchQuery就够用；如果你做的是类似SQL等于的精确筛选，一定用termQuery。把这两个概念烂熟于心，能少踩70%的查询坑。
4.2 bool复合查询：业务筛选条件怎么优雅组合
真实业务里几乎没有单纯一个字段的查询，要么是“分类A且价格区间B且名称含C”，要么是“符合(条件1或条件2)且不符合条件3”。这种逻辑用bool查询组合最清晰：
BoolQueryBuilder boolQuery = QueryBuilders.boolQuery() .must(QueryBuilders.termQuery("categoryId", "10023")) .must(QueryBuilders.rangeQuery("price").gte(100).lte(500)) .should(QueryBuilders.termQuery("brand", "某品牌")) .mustNot(QueryBuilders.termQuery("onSale", false)); SearchSourceBuilder sourceBuilder = new SearchSourceBuilder() .query(boolQuery) .from(0) .size(20) .sort("price", SortOrder.ASC);说一下bool查询的语义细节，因为这是多数人理解偏差最严重的点。must是必须匹配，参与相关度评分；filter也是必须匹配但不参与评分，性能更好，适合那些实质是过滤条件的约束，比如“价格在100到500之间”这种不需要影响排序的限定。我的习惯是，把业务上的筛选条件全部放filter，只有跟“搜索词”相关的才放must，这样大并发场景下还能利用ES的query cache。should在bool查询里不是必选，它的行为取决于有没有must/filter存在：如果下面挂了must或filter，should作为相关性加分项；如果只有should，则默认要求至少命中一个。要控制should的命中个数，可以用minimumShouldMatch参数。这个细节我在项目里花了很长时间才真正吃透，弄明白它能大幅减少无用的逻辑分支。
4.3 聚合把ES当统计工具用
ES的聚合查询是除了搜索之外最能体现价值的功能，能在毫秒级对几十亿文档做分组统计，这比在DB里跑group by快太多了。
最常见的聚合场景是两个：按某个字段分组计数，以及按日期分组看趋势。Java API写法：
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder() .size(0) .aggregation(AggregationBuilders .terms("by_category") .field("categoryId") .size(50)) .aggregation(AggregationBuilders .dateHistogram("by_hour") .field("createdAt") .calendarInterval(DateHistogramInterval.HOUR)); SearchResponse response = client.search( new SearchRequest("product").source(sourceBuilder), RequestOptions.DONE ); Terms agg = response.getAggregations().get("by_category"); for (Terms.Bucket bucket : agg.getBuckets()) { String key = bucket.getKeyAsString(); long count = bucket.getDocCount(); } ParsedDateHistogram dateHistogram = response.getAggregations().get("by_hour"); for (Histogram.Bucket bucket : dateHistogram.getBuckets()) { String key = bucket.getKeyAsString(); long count = bucket.getDocCount(); }聚合有几个性能相关的关键参数。第一个是size，terms聚合默认只返回Top 10，很多业务默认它返回所有桶，结果发现数据不全，这才回头把size调成一个大值。但size又不是越大越好，因为聚合是在每个分片上完成后归并到协调节点的，size太大会导致网络开销和内存暴涨。第二，聚合的字段必须是keyword或者开启fielddata的text，text字段默认不能聚合，这是ES出于内存保护的默认策略，你要是声明了"type": "text"就想terms聚合，直接报错。第三个坑是多层聚合，比如先按分类再按品牌，两个子聚合嵌套在父桶循环里去取结果，不要误写成并行的大聚合。
4.4 分页与排序：深分页的正确姿势
ES里最常见的分页写法就是from + size，比如第一页from=0 size=20，第二页from=20 size=20。这个写法在数据量小的时候没问题，但页面深了以后，协调节点需要把所有分片的结果都先拉过来排序，再截取目标区段，from越大消耗越大。几百页之内勉强能容忍，上万页之后性能直线往下掉。更致命的是还有一个默认最大上限：from+size默认不能超过10000，超过会直接报错“Result window is too large”。
深分页的解决方案按场景不同分两种。一种是适合导出全量或者系统间数据同步的scroll，它可以创造一个快照游标，分批拉取结果。注意scroll的快照在打开的窗口期内不会反映新写入的数据，不适合给用户实时查看。代码长这样：
SearchRequest searchRequest = new SearchRequest("product"); searchRequest.scroll(TimeValue.timeValueMinutes(1L)); SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DONE); String scrollId = searchResponse.getScrollId(); while (searchResponse.getHits().getHits().length > 0) { SearchScrollRequest scrollRequest = new SearchScrollRequest(scrollId); scrollRequest.scroll(TimeValue.timeValueMinutes(1L)); searchResponse = client.scroll(scrollRequest, RequestOptions.DONE); scrollId = searchResponse.getScrollId(); // 处理这一批数据 } // 结束后必须清掉scroll ClearScrollRequest clearScrollRequest = new ClearScrollRequest(); clearScrollRequest.addScrollId(scrollId); client.clearScroll(clearScrollRequest, RequestOptions.DONE);另一种是search_after，适合解决用户界面翻页但页码不固定的场景。它本质是用排序字段值作为游标，不依赖窗口大小，性能稳定。使用前提是排序字段必须唯一，一般带上文档id作为tiebreaker，否则相同排序值时结果会乱。search_after没有总页码的概念，所以前端要做“加载更多”的交互，而不是传统数字分页。如果业务必须支持跳页，比如用户直接点进第58页，那还是得用from+size硬扛，但可以考虑限制最大可翻页数，超过就用es的另一个机制或者换一个大窗口。
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder() .query(termQuery("categoryId", "10023")) .size(20) .sort("createdAt", SortOrder.DESC) .sort("_id", SortOrder.ASC) // tiebreaker .searchAfter(new Object[]{sortValue, docIdValue});5. 实战中踩过的坑与排查排障
干活三年，踩坑无数。这里把最典型的几个问题记录下来，一方面提醒自己，另一方面也希望后来人不用再趟一遍。
5.1 字段映射不一致导致的查询“神秘失效”
有一个印象非常深的案例：某天突然有同事反馈，说商品搜索中按品牌筛选的结果变少了。排查之后发现，品牌字段在最初设计时是text类型，后来因为支持模糊搜索的需求被改成了text+keyword。问题出在写入代码里，部分接口写入时用的是name字段的text部分，部分是keyword副本，导致一批文档的品牌信息没有写到keyword字段里，term查询当然在keyword字段查不到它。
这也能反过来验证一个原则：Mapping设计要提前、写入和查询的字段语义要统一。要么全部用keyword做筛选，要么全部用text做全文检索，别混着来。遇到这类问题，最快的定位方法是取一条“查不到”的文档，用_source返回完整内容，直接查看该字段存储的值是否符合预期。你用GET查询时，在Kibana里把字段的高亮打开，一眼就能看出来存的是全量值还是分词值。
5.2 连接池耗尽与线程阻塞
连接参数在第二章里已经讲了要点，这里说一说现象和排查思路。连接池耗尽的典型表现不是ES服务端报错，而是客户端抛出ConnectionPoolTimeoutException或者请求一直pending在同一阶段。用jstack抓线程栈时你会看到一堆线程卡在PoolingHttpClientConnectionManager的leasedEntry队列里，同时Tomcat线程数被占用殆尽。
排查路径一般是三步：先看ES集群的CPU和慢日志，排除服务端能力瓶颈；再看客户端连接池参数，是不是maxTotal和maxPerRoute在高峰期扛不住；最后才考虑网络层面和DNS解析耗时长的问题。我的经验是连接池容量按照服务端每秒查询量的峰值来估算，单客户端进程的maxConnTotal比较容易算：峰值QPS乘以平均查询耗时的乘积，再用4倍作为余量。比如平均单次查询200毫秒，QPS峰值1000，那么同时执行的请求数是200个，加上排队缓冲，maxConnTotal给到400-600，maxConnPerRoute给到200-300，这样能留足余量又不至于把客户端内存吃爆。
还有一点要注意：如果应用里同时操作多个ES集群，务必为每个集群创建专用的RestHighLevelClient，共用连接池会互相干扰，一个集群抖动整个应用跟着瘫痪。
5.3 版本冲突与并发更新
ES的版本号机制在并发更新场景下一半是保障、一半是麻烦。典型业务：给商品库存做扣减，两个线程同时读到库存=100，分别扣掉5和8，理论上最后应该是87，但如果按普通的update去做，后提交的线程基于旧版本100去做覆盖，最终结果变成92或者95，数据就错了。
正确做法有两种。一种是用脚本做原子运算：
Map<String, Object> params = Map.of("delta", 8); Script script = new Script( ScriptType.INLINE, "painless", "ctx._source.stock = ctx._source.stock - params.delta", params ); UpdateRequest updateRequest = new UpdateRequest("product", "1001").script(script); client.update(updateRequest, RequestOptions.DONE);脚本方式在ES端执行，天然原子，不涉及版本冲突。另一种是在业务里读取文档时拿到_seqno和_primary_term字段，做条件更新：
UpdateRequest updateRequest = new UpdateRequest("product", "1001") .doc(Map.of("stock", 92)) .setIfSeqNo(seqNo) .setIfPrimaryTerm(primaryTerm);如果其他线程改了文档，我的seq_no跟服务端不一致了，ES直接抛版本冲突，我们再重试。这种方式适合强一致要求高的场景，缺点是要多一次查询获取seq_no。我遇到的事务型业务都用后者骑在事务管理器上，非核心统计类的用脚本就够了。
5.4 大批量查询与内存保护
一个常见失误是想“全量拉取”，于是在代码里size设置成几百万，第一条就把ES搞挂了。ES针对单次查询也有个保护开关，max_result_window默认10000已经讲过，但就算调大了，协调节点也会把全部结果放进内存做排序，内存压力非常大。正确的全量拉取要么走scroll游标，要么按时间分片循环拉取，每次只取一页几千条。我做过一个数据同步任务，把商品库全量导到搜索引擎，正确的做法是按更新时间切片：第一次查最老一批，把返回的最后一个文档的更新时间当作下一次查询的下边界，循环推进。这种“时间窗口+searchAfter游标”的组合非常稳，内存占用几乎恒定，还能随意暂停续跑。
5.5 明明有数据却搜不到：refresh间隔的坑
ES写入默认是近实时的，写入后要等refresh间隔才可被搜索，默认1秒（8.x之前），8.0后改成了默认每秒刷新一次。如果你写入后立刻去查，可能会查到不结果，这不是查询写错了，而是还没refresh。测试或演示时可以把refresh_interval设成-1强制实时，或者写完主动调用refresh，但生产环境不要随便改。出现“刚写完查不到”的反馈时，先看是不是refresh没触发，再检查查询条件，别被这个问题分散了定位排查的注意力。
6. 排查工具与诊断技巧
最后这部分不是因为“要有排查经验”才写，而是确实想给刚上手ES的同仁一些可复用的方法。遇到问题先用Kibana的Dev Tools直接跑DSL，把Java代码的查询请求和返回用日志打出来，跟Kibana返回的结果做对比，大多数问题一眼就能定位。也建议在Service层加一个统一的查询日志AOP，打印入参DSL和出参耗时。时间一长，哪些查询慢、哪些条件是慢查询的根源，一目了然。
分析慢查询时优先看profile API。Java客户端支持把profile开关打开：
sourceBuilder.profile(true);返回内容里有每个Lucene子查询的耗时占比，一看便知道慢在倒排还是聚合还是排序，省去很多瞎猜时间。这个分析手段我每次排查慢查询都用，比任何监控都有针对性。
另外，遇到“查询结果和预期不一致”，先用_source把文档原文打出来看着，再判断是分词、类型、还是Mapping的问题。日志里面把请求的X-Request-Id或者文档id带上，能大大缩短联调时间。
写在最后
ES的Java API说简单也简单，就是Builder套Builder，说复杂也复杂，各种类型语义、版本差异和分布式特性叠加在一起，坑就藏在那些不起眼的默认参数里。我个人这几年的体会是：与其追求用上最新最全的API，不如先把term和match这类最基础的执行语义彻底搞清楚，对照业务场景想明白ES到底是怎么存数据、怎么找数据的，很多问题其实根本不用查资料就能推出来。上面分享的这些代码片段都是从真实项目里精简出来的，如果你正在做ES相关开发，建议直接复制到本地跑几个查询，感受一下不同语句对结果集的影响，这比看一百遍文档都管用。
