1. 为什么在 Spring Boot 项目里选 ElasticSearch 7.6.x 而不是别的版本
很多人在技术选型时容易陷入一个误区：看到 ElasticSearch 出了新版本就无脑升级，结果项目跑到一半发现客户端不兼容、API 大改、文档对不上。我自己在这个问题上反复折腾过好几轮，最后得出的结论是——版本选择不是越新越好，而是要看你的 Spring Boot 版本、业务体量和团队维护成本三者之间的平衡点。
ElasticSearch 7.6.x 这个版本在当下看来不算最新，但它是一个相当稳定的分水岭版本。为什么这么说？7.x 系列从 7.0 开始引入了大量破坏性变更，比如彻底移除了 TransportClient 的支持、默认开启了安全认证、引入了新的集群协调机制。而 7.6.x 正好处于这些重大变更已经稳定、但还没有引入后续 7.10 之后那些更激进的特性调整的阶段。对于大多数中小规模的搜索业务来说，7.6.x 提供的功能已经完全够用，而且社区资料丰富，踩坑成本低。
再来看 Spring Boot 这边的配合。如果你用的是 Spring Boot 2.3.x 到 2.7.x 之间的版本，Spring Data Elasticsearch 的 4.x 系列对 ES 7.6.x 的支持是最成熟的。特别是 spring-data-elasticsearch 4.0.x 到 4.4.x 这几个版本，底层用的是 Elasticsearch RestHighLevelClient，虽然这个客户端在后续版本中被标记为废弃，但在 7.6.x 的语境下，它反而是最稳妥的选择。你要是硬上 Elasticsearch Java API Client 8.x，那 Spring Boot 版本也得跟着大改，连锁反应太大。
还有一个很现实的问题：你的服务器环境。很多公司的运维团队对 JDK 版本、操作系统内核参数、内存分配都有既定规范。ES 7.6.x 对 JDK 的要求是 JDK 8 以上，推荐 JDK 11，这个门槛很低。而 ES 8.x 强制要求 JDK 17，很多老项目的生产环境根本升不上去。所以选 7.6.x 很多时候不是技术偏好，而是被环境倒逼的理性决策。
注意：如果你现在是从零开始搭建一个全新项目，且团队没有历史包袱，那可以考虑更新的版本。但如果你是在维护一个已经上线的 Spring Boot 项目，需要快速接入搜索能力，7.6.x 配合 Spring Data Elasticsearch 4.x 是性价比最高的组合。
2. 环境搭建中最容易翻车的三个环节
2.1 ES 服务端的安装与关键配置调整
安装 ElasticSearch 7.6.x 本身不复杂，下载解压就能跑，但默认配置直接用于生产或者稍大一点的数据量测试，几乎必然出问题。我见过太多人装完之后发现服务起不来，或者起来了但一写入数据就卡死，根因往往就集中在几个参数上。
第一个要改的是jvm.options里的堆内存。默认配置是 1GB，对于开发环境勉强够用，但你只要建几个索引、灌几万条数据，GC 就会频繁触发。我的经验是：单节点开发环境给 2GB 到 4GB，生产环境根据数据量给物理内存的 50%，但绝对不要超过 31GB。为什么是 31GB？因为 JVM 在堆内存超过 32GB 时会关闭指针压缩，反而导致性能下降。这个细节很多人不知道，以为内存给得越大越好。
第二个是elasticsearch.yml里的network.host和discovery.seed_hosts。7.x 版本对集群发现机制做了调整，单节点模式下你需要显式设置discovery.type: single-node，否则它会尝试以多节点模式启动，然后因为找不到其他节点而报错。这个坑我在第一次部署时踩过，日志里一堆master not discovered的警告，排查了半天才发现是少了这一行配置。
第三个是文件描述符和虚拟内存的限制。Linux 系统默认的ulimit -n是 1024，而 ES 需要至少 65536。你需要在/etc/security/limits.conf里加上elasticsearch soft nofile 65536和elasticsearch hard nofile 65536。另外vm.max_map_count要设置成 262144，否则 ES 启动时会直接报错退出。这些系统层面的参数调整，在容器化部署时尤其容易被忽略。
# 检查当前系统参数 sysctl vm.max_map_count ulimit -n # 临时调整（重启失效） sysctl -w vm.max_map_count=262144 ulimit -n 65536 # 永久生效需要修改 /etc/sysctl.conf 和 /etc/security/limits.conf2.2 Spring Boot 项目中依赖版本的精确匹配
依赖冲突是 Spring Boot 整合 ES 时最让人头疼的问题，没有之一。Spring Boot 的 starter 机制虽然方便，但它对 Spring Data Elasticsearch 的版本管理有时候会和你想用的 ES 服务端版本产生偏差。
以 Spring Boot 2.3.x 为例，它默认管理的 Spring Data Elasticsearch 版本是 4.0.x，这个版本对应支持的 ES 服务端是 7.6.x。看起来正好对吧？但如果你在pom.xml里手动引入了elasticsearch-rest-high-level-client，而没有指定版本号，Maven 可能会拉取一个和你 ES 服务端不匹配的版本，导致运行时出现NoSuchMethodError或者序列化异常。
我的做法是：在dependencyManagement里显式锁定所有 ES 相关依赖的版本。具体来说，需要锁定的包括elasticsearch、elasticsearch-rest-high-level-client、elasticsearch-rest-client这三个核心包。版本号统一写成 7.6.2，这是 7.6.x 系列里比较稳定的一个小版本。
<properties> <elasticsearch.version>7.6.2</elasticsearch.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch</artifactId> <version>${elasticsearch.version}</version> </dependency> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-high-level-client</artifactId> <version>${elasticsearch.version}</version> </dependency> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-client</artifactId> <version>${elasticsearch.version}</version> </dependency> </dependencies> </dependencyManagement>还有一个隐藏的坑：Spring Boot 的spring-boot-starter-data-elasticsearch默认会传递依赖elasticsearch-rest-high-level-client，但版本可能不是你想要的。你需要在引入 starter 的同时，排除掉它自带的 ES 客户端依赖，然后手动引入你锁定的版本。这一步不做的话，版本冲突几乎必然发生。
2.3 连接配置中的超时与重试策略
默认的 ES 连接配置非常保守，连接超时 1 秒，Socket 超时 30 秒，重试次数 1 次。在开发环境可能感觉不到问题，但一旦网络稍有波动或者 ES 集群负载升高，你的应用就会频繁抛出ConnectTimeoutException或者SocketTimeoutException。
我在一个日请求量百万级的项目里做过统计，超过 60% 的 ES 查询异常都是超时导致的，而不是真正的服务不可用。所以连接池和超时参数的调优非常关键。RestHighLevelClient 底层用的是 Apache HttpClient，你可以通过RestClientBuilder自定义这些参数。
@Configuration public class ElasticSearchConfig { @Bean public RestHighLevelClient restHighLevelClient() { RestClientBuilder builder = RestClient.builder( new HttpHost("localhost", 9200, "http")) .setRequestConfigCallback(requestConfigBuilder -> requestConfigBuilder .setConnectTimeout(5000) .setSocketTimeout(60000) .setConnectionRequestTimeout(10000)) .setHttpClientConfigCallback(httpClientBuilder -> httpClientBuilder .setMaxConnTotal(100) .setMaxConnPerRoute(50) .setKeepAliveStrategy((response, context) -> TimeUnit.MINUTES.toMillis(5))); return new RestHighLevelClient(builder); } }这里有几个参数值得展开说。setConnectTimeout设成 5 秒，是因为建立 TCP 连接本身不应该花太久，如果 5 秒还连不上，说明网络或者服务端确实有问题，早点失败比一直等着好。setSocketTimeout设成 60 秒，是因为复杂的聚合查询或者大结果集返回可能需要较长时间，设太短会导致查询被中断。setMaxConnTotal和setMaxConnPerRoute控制连接池大小，根据你的并发量调整，一般建议总连接数不超过 200，单路由不超过 100。
提示：如果你用的是 Spring Data Elasticsearch 的
ElasticsearchRestTemplate，它内部会使用你配置的RestHighLevelClient，所以这些参数同样生效。但要注意，ElasticsearchRestTemplate自己也有一些查询级别的超时设置，需要在具体查询时通过SearchRequest指定。
3. 索引映射设计与文档操作的实战细节
3.1 用注解还是用 JSON 定义 Mapping
Spring Data Elasticsearch 提供了两种定义索引映射的方式：一种是用@Document、@Field等注解在实体类上标注，另一种是直接写 JSON 格式的 mapping 文件。这两种方式各有适用场景，选错了会给后续维护带来很大麻烦。
注解方式的优点是代码即文档，实体类和映射定义在一起，修改字段时不容易遗漏。但它的缺点也很明显：对于复杂的嵌套类型、自定义分词器、多字段（fields）配置，注解的表达能力有限。比如你想给一个title字段同时配置text类型用于全文搜索和keyword类型用于聚合排序，用注解写起来就很别扭。
我的建议是：简单业务用注解，复杂业务用 JSON 文件配合@Mapping注解。具体来说，如果你的索引只有几个基本字段，类型都是text、keyword、long、date这些，那直接用注解没问题。但如果你需要配置ik分词器、nested嵌套对象、completion自动补全，那就老老实实写 JSON 文件，然后在实体类上用@Mapping(mappingPath = "xxx.json")引入。
@Document(indexName = "article_index", shards = 3, replicas = 1) @Setting(settingPath = "es-settings/article-settings.json") @Mapping(mappingPath = "es-mappings/article-mapping.json") public class Article { @Id private String id; @Field(type = FieldType.Text, analyzer = "ik_max_word") private String title; @Field(type = FieldType.Keyword) private String author; // 省略其他字段 }这里有个细节要注意：@Setting和@Mapping指定的 JSON 文件路径是相对于resources目录的。而且这些文件只在索引首次创建时生效，如果索引已经存在，Spring Data Elasticsearch 不会自动更新映射。你需要手动调用IndexOperations.putMapping()来更新，或者干脆删了重建。生产环境删索引是大忌，所以更新映射前一定要确认好兼容性。
3.2 批量写入的性能优化与内存控制
单条写入 ES 的效率非常低，每写一条都要走一次网络往返，在数据量大的场景下完全不可接受。批量写入（Bulk API）是必须用的，但 Bulk 的使用也有很多讲究。
首先是批次大小的选择。很多人以为批次越大越好，一次塞几千条甚至上万条，结果发现内存飙升、GC 频繁，甚至 OOM。根据我的实测经验，单批次 500 到 1000 条文档，或者总大小控制在 5MB 到 10MB 之间，是比较合理的范围。这个数值不是拍脑袋来的，ES 官方文档也建议 Bulk 请求的总体积不要超过 10MB，否则协调节点处理起来压力很大。
其次是并发控制。Bulk 操作本身是同步的，如果你用多线程并发发送 Bulk 请求，确实能提高吞吐量，但线程数不是越多越好。ES 的写入瓶颈通常在磁盘 I/O 和 Lucene 的段合并上，并发太高反而会导致段合并跟不上，出现写入阻塞。我一般会把并发线程数控制在 CPU 核心数的 1.5 到 2 倍左右。
public void bulkIndex(List<Article> articles) { int batchSize = 500; for (int i = 0; i < articles.size(); i += batchSize) { int end = Math.min(i + batchSize, articles.size()); List<Article> batch = articles.subList(i, end); BulkRequest bulkRequest = new BulkRequest(); for (Article article : batch) { IndexRequest indexRequest = new IndexRequest("article_index") .id(article.getId()) .source(JSON.toJSONString(article), XContentType.JSON); bulkRequest.add(indexRequest); } try { BulkResponse response = restHighLevelClient.bulk(bulkRequest, RequestOptions.DEFAULT); if (response.hasFailures()) { // 处理失败条目，记录日志或重试 log.error("Bulk index has failures: {}", response.buildFailureMessage()); } } catch (IOException e) { log.error("Bulk index failed", e); } } }还有一个容易被忽略的点：Bulk 请求的刷新策略。默认情况下，ES 每 1 秒刷新一次索引，这意味着你刚写入的数据要等最多 1 秒才能被搜索到。如果你在做数据迁移或者批量导入，可以临时把refresh_interval设为-1（关闭自动刷新），等全部导入完成后再手动刷新一次。这样能大幅提升写入速度，我实测过，关闭自动刷新后写入吞吐量能提升 30% 到 50%。
3.3 文档更新的几种姿势与选择依据
ES 的文档更新不像关系型数据库那样直接UPDATE就完事了，它底层其实是"标记删除 + 新建文档"的过程。理解这一点很重要，因为它直接影响到你的更新策略选择。
最常用的更新方式是UpdateRequest，它支持两种模式：一种是传入完整的文档内容进行覆盖，另一种是传入脚本（script）进行局部更新。覆盖式更新的好处是简单直接，坏处是如果你只想改一个字段，也得把整个文档重新传一遍，网络开销大，而且并发情况下容易覆盖掉别人的修改。
脚本更新则灵活得多，可以只修改指定字段，还支持原子性的数值增减、数组追加等操作。但脚本更新也有代价：Painless 脚本的执行效率比直接覆盖要低，而且调试起来麻烦。我在一个计数器场景里用过脚本更新，QPS 大概比覆盖式低了 20% 左右。
// 覆盖式更新 public void updateArticle(Article article) { UpdateRequest updateRequest = new UpdateRequest("article_index", article.getId()) .doc(JSON.toJSONString(article), XContentType.JSON); try { restHighLevelClient.update(updateRequest, RequestOptions.DEFAULT); } catch (IOException e) { log.error("Update failed", e); } } // 脚本式局部更新 public void incrementViewCount(String articleId, int increment) { UpdateRequest updateRequest = new UpdateRequest("article_index", articleId) .script(new Script(ScriptType.INLINE, "painless", "ctx._source.viewCount += params.increment", Collections.singletonMap("increment", increment))); try { restHighLevelClient.update(updateRequest, RequestOptions.DEFAULT); } catch (IOException e) { log.error("Script update failed", e); } }选择哪种方式，我的判断标准是：如果每次更新都是全量字段变更，用覆盖式；如果只改少数几个字段，尤其是需要原子操作的数值字段，用脚本式。另外，ES 7.x 还支持_update_by_query，可以按条件批量更新，但这个操作开销很大，不建议在高频业务中使用，更适合数据修复场景。
4. 查询构建：从简单匹配到复杂聚合的完整路径
4.1 QueryBuilder 的组合逻辑与常见误用
Spring Data Elasticsearch 的NativeSearchQueryBuilder是对 ES 查询 DSL 的一层封装，用起来比手写 JSON 方便，但也容易写出性能很差的查询。我见过最常见的误用是把must、should、filter混着用，导致本该走 filter 缓存的查询走了评分计算，白白浪费 CPU。
先理清一个基本概念：must和should会影响文档评分（_score），而filter不会。如果你的查询条件只是用来筛选数据，不关心相关性排序，那就应该用filter而不是must。ES 会对 filter 的结果进行缓存，重复查询时速度极快。而must每次都要重新计算评分，开销大得多。
// 不推荐的写法：用 must 做纯筛选 BoolQueryBuilder badQuery = QueryBuilders.boolQuery() .must(QueryBuilders.termQuery("status", 1)) .must(QueryBuilders.rangeQuery("createTime").gte("2024-01-01")); // 推荐的写法：用 filter 做筛选 BoolQueryBuilder goodQuery = QueryBuilders.boolQuery() .filter(QueryBuilders.termQuery("status", 1)) .filter(QueryBuilders.rangeQuery("createTime").gte("2024-01-01"));另一个常见问题是term和match的混用。term是精确匹配，不会对查询词进行分词，适合keyword类型字段。match会先对查询词分词，然后去匹配text类型字段的分词结果。如果你对一个text字段用term查询，除非你传的值正好和分词后的某个词元完全一致，否则查不到任何结果。这个坑我在早期项目中踩过，明明数据存在却搜不出来，排查了半天才发现是查询类型用错了。
4.2 分页查询的深分页问题与 search_after 方案
分页是搜索业务里绕不开的需求，但 ES 的分页有一个著名的"深分页"问题。当你用from+size做分页时，ES 需要从每个分片上取出from + size条文档，然后在协调节点进行排序和截取。当from很大时（比如第 1000 页），每个分片都要返回大量数据，协调节点的内存和 CPU 压力会急剧上升。
ES 默认的index.max_result_window是 10000，也就是说from + size不能超过这个值。你可以调大这个参数，但治标不治本，深分页的性能问题依然存在。真正的解决方案是使用search_after，它基于上一页最后一条文档的排序值来定位下一页的起始位置，不需要跳过前面的文档。
public List<Article> searchAfter(String lastSortValue, int size) { SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); sourceBuilder.size(size); sourceBuilder.sort("createTime", SortOrder.DESC); sourceBuilder.sort("_id", SortOrder.ASC); // 保证排序唯一性 if (lastSortValue != null) { sourceBuilder.searchAfter(new Object[]{lastSortValue}); } SearchRequest searchRequest = new SearchRequest("article_index"); searchRequest.source(sourceBuilder); try { SearchResponse response = restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT); return Arrays.stream(response.getHits().getHits()) .map(hit -> JSON.parseObject(hit.getSourceAsString(), Article.class)) .collect(Collectors.toList()); } catch (IOException e) { log.error("Search after failed", e); return Collections.emptyList(); } }search_after的缺点是不能随机跳页，只能一页一页往后翻。但对于大多数搜索场景来说，用户很少会翻到很后面的页码，所以这个限制在实际业务中影响不大。如果你的产品确实需要跳页功能，可以考虑用scrollAPI 做数据导出，或者在前端做限制，只允许翻到前 100 页。
4.3 聚合分析的嵌套结构与性能考量
聚合是 ES 的杀手锏功能之一，但嵌套聚合写起来容易让人头晕。我见过不少人在terms聚合里套terms聚合，再套avg聚合，结果查询慢得没法看。问题往往出在两个方面：一是聚合字段没有用keyword类型，导致 ES 需要对text字段做 fielddata 加载，内存消耗巨大；二是聚合层级太深，每一层都要遍历所有文档。
正确的做法是：聚合字段一律用keyword类型，或者在text字段上配置fields子字段。比如title字段定义为text并带一个keyword子字段title.keyword，聚合时用title.keyword。这样 ES 可以直接利用倒排索引的 doc values 做聚合，不需要额外加载 fielddata。
// 聚合示例：按作者分组，统计每组的平均浏览量 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); sourceBuilder.size(0); // 不需要返回文档，只要聚合结果 TermsAggregationBuilder authorAgg = AggregationBuilders .terms("by_author") .field("author.keyword") .size(20) .subAggregation(AggregationBuilders.avg("avg_views").field("viewCount")); sourceBuilder.aggregation(authorAgg); SearchRequest searchRequest = new SearchRequest("article_index"); searchRequest.source(sourceBuilder); SearchResponse response = restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT); Terms byAuthor = response.getAggregations().get("by_author"); for (Terms.Bucket bucket : byAuthor.getBuckets()) { String author = bucket.getKeyAsString(); Avg avgViews = bucket.getAggregations().get("avg_views"); log.info("Author: {}, Avg views: {}", author, avgViews.getValue()); }还有一个性能优化点：聚合的size不要设得太大。terms聚合默认返回前 10 个桶，如果你设成 1000，ES 需要在协调节点合并大量数据。如果确实需要返回很多桶，可以考虑用composite聚合做分页，它比terms聚合更适合大数据量的分组场景。
5. 那些文档里不会写的踩坑记录与排查思路
5.1 索引创建成功但写入报错的诡异问题
有一次我在一个新环境里部署应用，索引创建明明成功了，@Document注解也生效了，但一写入数据就报mapper_parsing_exception。错误信息说某个字段的类型不匹配，但我检查了实体类定义和 mapping，看起来完全一致。
排查过程是这样的：先看 ES 服务端的日志，发现它收到的文档里，那个字段的值是一个 JSON 对象，但 mapping 里定义的是text类型。问题出在序列化上——我用的是 FastJSON 做 JSON 转换，而实体类里那个字段是一个枚举类型，FastJSON 默认把枚举序列化成了对象形式{"code": 1, "desc": "xxx"}，而不是字符串。
这个问题的根因是序列化框架和 ES mapping 之间的语义鸿沟。Spring Data Elasticsearch 默认用的是 Jackson，但我为了和其他模块保持一致换成了 FastJSON，结果就出了这个问题。解决方案有两个：要么给枚举字段加@JSONField(format = "ordinal")或者自定义序列化器，要么换回 Jackson。我最后选择了后者，因为 Jackson 和 Spring Data Elasticsearch 的集成更原生，少一层适配就少一个坑。
提示：如果你在实体类里用了
LocalDateTime、BigDecimal、枚举这些类型，一定要确认你的序列化框架输出的格式和 ES mapping 定义的类型一致。LocalDateTime默认序列化成数组[2024,1,1,12,0,0]的情况我都见过，这种问题不报错才怪。
5.2 集群健康状态黄色甚至红色的处理路径
GET _cluster/health返回黄色状态，意味着主分片都正常，但副本分片没有分配。对于单节点集群来说，这是正常现象，因为你只有一个节点，副本分片无处可放。但如果是多节点集群出现黄色，那就要排查了。
我遇到过一次三节点集群变黄的情况，排查下来是因为其中一个节点的磁盘使用率超过了 85%，ES 默认的cluster.routing.allocation.disk.watermark.high是 90%，超过后会自动把分片从该节点迁走。但另外两个节点的磁盘也不宽裕，迁不过去，就卡在黄色状态了。
处理这类问题的步骤是：先看_cat/allocation?v确认各节点的磁盘使用情况，再看_cat/shards?v找出哪些分片处于UNASSIGNED状态，然后根据具体原因处理。如果是磁盘问题，清理旧索引或者扩容；如果是节点掉线，重启节点后 ES 会自动恢复分片分配。
# 查看集群健康状态 curl -X GET "localhost:9200/_cluster/health?pretty" # 查看分片分配情况 curl -X GET "localhost:9200/_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason" # 查看磁盘使用 curl -X GET "localhost:9200/_cat/allocation?v"红色状态则意味着有主分片未分配，部分数据不可用。这种情况通常比较严重，可能是节点故障导致数据丢失。如果确认数据有备份，最快的恢复方式是重建索引然后重新导入数据。如果没有备份，那就只能尝试用elasticsearch-shard工具修复损坏的分片，但成功率不高。
5.3 查询结果与预期不符时的逐层排查法
搜索出来的结果不对，可能的原因非常多：分词器配置问题、字段类型问题、查询语句问题、数据本身的问题。我总结了一套逐层排查的方法，能比较快地定位到根因。
第一步，用_analyzeAPI 确认分词结果。比如你搜"北京大学"搜不到，先看看ik_max_word把它分成了什么词。如果分词结果里没有你期望的词元，那就是分词器的问题。
curl -X POST "localhost:9200/article_index/_analyze" -H 'Content-Type: application/json' -d' { "analyzer": "ik_max_word", "text": "北京大学" }'第二步，用_explainAPI 查看某条文档为什么没有匹配上。它会返回详细的评分计算过程，告诉你哪个查询子句匹配了、哪个没匹配。
第三步，检查查询语句本身。把NativeSearchQueryBuilder构建出来的SearchSourceBuilder打印出来，看看生成的 JSON 是不是你期望的。有时候QueryBuilders的链式调用顺序不对，会导致生成的 DSL 结构和你想象的不一样。
第四步，确认数据是否真的写进去了。用_countAPI 或者简单的match_all查询看看索引里到底有多少条数据。我遇到过数据写入时因为refresh_interval设置过长，导致刚写入的数据查不到的情况，等几秒就好了。
6. 生产环境下的性能调优与监控要点
6.1 写入性能的瓶颈定位与参数调整
生产环境的写入性能问题，十有八九出在段合并（segment merge）上。ES 的写入模型是"写入内存缓冲 → 生成新段 → 定期合并小段"，当写入速度超过合并速度时，就会触发写入阻塞（write throttle），表现为 Bulk 请求响应时间飙升。
定位这个问题的方法是看_nodes/stats/indices/segments里的merges.current和merges.total_time_in_millis。如果current长期大于 0，说明合并跟不上。这时候可以考虑调整index.merge.scheduler.max_thread_count，默认是Math.min(4, 处理器核心数 / 2)，对于机械硬盘可以调低到 1，对于 SSD 可以适当调高。
另一个影响写入性能的参数是index.transitlog.durability。默认是request，意味着每次请求都要 fsync 到磁盘，保证数据不丢。如果你能接受少量数据丢失的风险，可以改成async，让 ES 每 5 秒刷一次磁盘，写入性能会有明显提升。但生产环境改这个参数要慎重，最好和业务方确认数据可靠性要求。
6.2 查询慢的常见原因与优化手段
查询慢的原因比写入慢更复杂，我按出现频率从高到低列一下：深分页、大聚合、通配符前缀查询、脚本查询、字段类型不匹配导致的 fielddata 加载。
深分页和大聚合前面已经说过了，这里重点说通配符查询。wildcard查询和prefix查询在 ES 里都是逐词遍历的，效率很低。如果你需要前缀匹配，更好的方案是用completionsuggester 或者edge_ngram分词器。completionsuggester 底层用的是 FST 数据结构，查询速度极快，适合自动补全场景。
// 不推荐：wildcard 前缀查询 QueryBuilders.wildcardQuery("title.keyword", "Java*"); // 推荐：用 completion suggester 做自动补全 // 首先在 mapping 里定义 completion 类型字段 // "suggest": { "type": "completion", "analyzer": "ik_max_word" } SuggestBuilder suggestBuilder = new SuggestBuilder(); suggestBuilder.addSuggestion("title_suggest", SuggestBuilders.completionSuggestion("suggest") .prefix("Java") .size(10));脚本查询的优化空间有限，如果非用不可，尽量用painless脚本并开启缓存。ES 对脚本有编译缓存，相同脚本的第二次执行会快很多。另外，能用runtime field替代脚本的地方尽量用 runtime field，它在 7.11 之后支持，但 7.6.x 没有这个功能，所以只能靠脚本优化。
6.3 监控指标的选择与告警阈值设定
ES 的监控指标有几百个，但真正需要关注的核心指标就那么十几个。我一般会重点看这几类：集群健康状态、JVM 堆内存使用率、GC 次数和耗时、磁盘使用率、查询和写入的延迟与拒绝率。
JVM 堆内存使用率长期超过 75% 就要警惕了，超过 85% 基本离 OOM 不远了。GC 方面，Young GC 频繁但耗时短是正常的，如果 Old GC 频繁且单次超过 1 秒，说明堆内存压力很大，需要考虑扩容或者优化查询减少内存占用。
磁盘使用率我建议设两级告警：80% 预警，85% 严重告警。因为 ES 默认的 low watermark 是 85%，到了这个阈值它就开始限制分片分配了。查询拒绝率（_nodes/stats/thread_pool里的rejected）如果持续大于 0，说明线程池满了，要么是查询太慢占着线程不放，要么是并发太高，需要调整线程池大小或者限流。
# 查看关键监控指标 curl -X GET "localhost:9200/_cluster/health?pretty" curl -X GET "localhost:9200/_nodes/stats/jvm,os,thread_pool?pretty" curl -X GET "localhost:9200/_cat/indices?v&h=index,health,pri,rep,docs.count,store.size"注意：ES 7.x 自带的监控功能比较基础，如果你需要更细粒度的监控和告警，可以考虑接入外部的监控系统。但不管用什么工具，上面这些核心指标都是必须采集的。
7. 版本升级与数据迁移的稳妥策略
7.1 从旧版本迁移到 7.6.x 的路径规划
如果你现有的 ES 集群是 6.x 甚至 5.x，想迁移到 7.6.x，不能直接滚动升级，必须经过中间版本。ES 官方支持的升级路径是：5.x → 6.x → 7.x，不能跳版本。而且 6.x 到 7.x 的升级有很多破坏性变更，比如_type概念被移除、_all字段被废弃、默认分词器行为调整等。
我的建议是：如果数据量不大，最稳妥的方式是新建一个 7.6.x 集群，然后用 reindex 或者 Logstash 把数据从旧集群迁移过来，应用层做双写过渡，最后切流量。这种方式虽然需要额外的硬件资源，但风险最低，出问题可以随时回滚。
如果数据量很大，无法一次性迁移，那就只能做滚动升级。滚动升级的步骤是：先升级一个节点，等它加入集群并同步完数据，再升级下一个。但 6.x 到 7.x 的滚动升级要求集群先升级到 6.8 版本，然后才能升 7.x。这个过程可能需要停机维护，要提前和业务方沟通好。
7.2 索引重建与别名切换的无缝方案
不管是什么原因需要重建索引（比如修改 mapping、升级分词器、调整分片数），别名切换都是实现零停机的关键。基本思路是：创建一个新索引，把数据导进去，然后原子性地把别名从旧索引切到新索引。
# 创建新索引 curl -X PUT "localhost:9200/article_index_v2" -H 'Content-Type: application/json' -d' { "settings": { "number_of_shards": 3, "number_of_replicas": 1 }, "mappings": { ... } }' # 用 reindex 迁移数据 curl -X POST "localhost:9200/_reindex?wait_for_completion=false" -H 'Content-Type: application/json' -d' { "source": { "index": "article_index_v1" }, "dest": { "index": "article_index_v2" } }' # 原子性切换别名 curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d' { "actions": [ { "remove": { "index": "article_index_v1", "alias": "article_index" } }, { "add": { "index": "article_index_v2", "alias": "article_index" } } ] }'这个方案的关键点是：应用层始终通过别名访问索引，不直接写具体索引名。这样切换别名时应用完全无感知。另外，reindex 是一个耗时操作，建议用wait_for_completion=false异步执行，然后通过_tasksAPI 查看进度。
7.3 升级后的回归验证清单
升级完成后，不要急着把全部流量切过来，先做一轮回归验证。我一般会检查这几项：索引的 mapping 是否和预期一致、分词器的分词结果是否正确、查询结果的数量和排序是否正常、聚合结果是否准确、写入性能是否达标。
分词器这块特别容易出问题，因为不同版本的ik分词器词典可能不一样，同一个词在旧版本和新版本里的分词结果可能不同。如果你的业务对分词精度要求很高，升级前一定要用_analyzeAPI 对比新旧版本的分词结果。
写入性能的验证可以用一个简单的压测脚本，往新集群写入一批测试数据，对比升级前后的写入吞吐量和延迟。如果发现性能下降明显，先别切流量，排查一下是不是新版本的默认配置有变化，比如refresh_interval或者translog的设置。
我个人在实际操作中的体会是，ES 的版本升级从来不是技术问题，而是流程问题。只要把升级路径规划好、数据迁移方案验证好、回滚方案准备好，剩下的就是按部就班执行。最怕的是没有回滚方案就贸然升级，出了问题只能干瞪眼。所以不管多急，升级前一定要确认旧集群还能正常提供服务，新集群验证通过后再切流量。
