SpringBoot集成Elasticsearch 7.x实战：starter方式从入门到落地

1. 项目概述与集成思路拆解

老朋友都知道，SpringBoot 项目里接 Elasticsearch 的姿势其实不止一种。有人直接用 RestHighLevelClient 手写一堆连接代码，有人用 Spring Data Elasticsearch 封装好的模板类，还有人图省事直接拿 HTTP 接口拼接 JSON。而今天要聊的 spring-boot-starter-data-elasticsearch，是官方提供的一条“省心但不呆板”的集成路线：既能用声明式 Repository 快速完成增删改查，又保留了 ElasticsearchOperations 让你在复杂查询上随心所欲。

老实说，我最早经历的是“没有 starter 的时代”。当时要么自己封装 RestClient，要么在 XML 配置里堆一堆 FactoryBean，每次升级 ES 版本都得跟着改一遍连接层代码。后来 Spring Data Elasticsearch 逐渐成熟，spring-boot-starter-data-elasticsearch 把底层客户端的初始化、连接池管理、Json 序列化、索引映射这一套事情全部托管掉，开发者只需要关注索引模型和查询逻辑本身。这篇文章就是基于我在实际项目里用这套 starter 对接 ES 7.x 的完整经验整理出来的，适合刚从零开始接 ES 的 SpringBoot 开发者，也适合那些已经在用原生 Client、想规范化的团队作为参考。

我这里说的“7.x”，确切点讲，是指 Elasticsearch 7.6 到 7.17 这个区间，对应 Spring Data Elasticsearch 4.0 到 4.4 系列。如果你用的是 ES 8.x，那又是另一套玩法，rest 客户端和 Spring Data 的 API 都有不少差异，咱这篇文章还是严格聚焦 7.x。下面我会把版本匹配、环境搭建、实体映射、Repository 查询、复杂搜索、批量写入，再到生产环境的常见故障，一条龙讲透。

1.1 三条主流集成路线，为什么我推荐 starter

先拉个对比，把市面上常用的三种接法摊开看：

第一种方式是很多老项目在用的，自己 new 一个 RestHighLevelClient，把地址、认证信息写进配置类，然后写一堆 searchRequest、putMappingRequest。这种方式的优点是没有中间层，性能损耗最小，但缺点也明显：样板代码多，索引映射要靠手写 JSON 字符串，连个分页查询都得自己组装 SearchSourceBuilder。时间一长，项目中就会出现大量工具类和重复代码。

第三种直接调 HTTP 接口，适合一些轻量场景，比如定时任务里拉数据、或者非 Java 技术栈顺便调一下，但真要是做核心搜索业务，代码量能翻三倍不止。排序、聚合、高亮这种功能，手拼 JSON 很容易出错，而且没有类型安全，线上出了个 Query 解析错误，排查半天心态崩溃。

而 spring-boot-starter-data-elasticsearch 的定位，说白了就是“Spring 生态的一等公民”。它自动配置好了客户端和模板，提供了 @Document、@Field 这种注解式映射，Repository 写接口名就能生成查询，同时在需要时你还能拿到 ElasticsearchOperations 做 Native 查询。它是“既要省事，又不想被框架卡死”的折中方案，也是绝大多数 SpringBoot 项目的默认选项。

1.2 starter 方式到底自动帮你干了什么

很多人只知道引入依赖就能用，却没搞明白背后它替你做了几件事。总结下来，核心有三点：

第一，客户端对象的创建与销毁。ElasticsearchRestClientAutoConfiguration 会读取 spring.elasticsearch.rest.* 配置，自动构建 RestHighLevelClient（7.x 时代底层还是这个），包括连接地址、连接超时、socket 超时、认证信息。你不用担心客户端没有正确关闭导致连接泄漏，Spring 容器销毁时会帮你处理。

第二，模板类和 Repository 的装配。ElasticsearchRestTemplate（接口类型是 ElasticsearchOperations）作为核心操作入口被注入容器，凡是标注了 @EnableElasticsearchRepositories（其实 starter 默认会开启扫描）的项目，你的 Repository 接口都会被动态代理生成实现。

第三，结果集与实体的转换。搜索返回的 JSON 会自动反序列化成你的实体对象，时间类型、嵌套对象、数组这些转换处理，由框架帮你兜底。你只需要保证字段名或者 @Field 注解配置正确，其他不用管。

听着是挺美，但它也有“脾气”：版本匹配要求严格，索引映射在某些场景下过于“自作主张”，以及实体类一旦设计不好，查询会变得很别扭。这些坑我在后面章节都会展开。

1.3 什么项目适合走 starter 这条路

根据我带过多个项目的经验，适合选择 starter 的典型场景包括：内部管理系统需要给列表页加个模糊搜索、电商或内容平台需要商品/文章索引、日志或业务数据需要做一些简单聚合分析。这些项目普遍要求“快速落地、规范统一”，并不需要把 ES 用到极致性能。

反过来，如果你的项目是搜索中台或者 To B 的高性能搜索网关，每天的 QPS 很大，对查询的每一个环节的字节级控制都有要求，那原生 Client 更合适。还有一种情况，项目里已经打下了大量 RestHighLevelClient 的工具代码，我再看到新模块又引入 starter，两个连接方式并存，那纯粹给自己找罪受。迁移需谨慎，新老并存大概率会出现客户端管理混乱和查询行为不一致的问题。

一句话总结：starter 适合绝大多数“用 ES 做业务功能”的项目，而不适合“把 ES 本身做成业务”的项目。想清楚这一点，再决定要不要往下走。

2. 环境准备：Elasticsearch 7.x 与 Spring Boot 版本匹配

选定 starter 之后，第一个大坑就是环境。我不止一次见过同事把 Elasticsearch 8.5 的包下载下来，然后拿着 Spring Boot 2.5 的 starter 去连，结果连不上、报各种兼容性错误。ES 版本和 Spring Data Elasticsearch 版本是严丝合缝对应的，这种版本敏感度比 MySQL、Redis 要高得多，必须一开始就规划好。

2.1 Elasticsearch 7.x 本地快速搭建

先解决 ES 服务端本身的问题。如果你是 Windows 环境，去官网下载 7.17.x 的 zip 包，解压后进入 bin 目录，双击 elasticsearch.bat 就能启动，默认监听 9200 端口。第一次启动如果报“could not find java”这类问题，说明本机没有 JDK，ES 7.x 自带了一个捆绑的 JDK 在 jdk 目录里，不过它优先用环境变量里的 JAVA_HOME，建议还是装个 JDK 8/11 环境都行。启动日志里看到 "message":"started"，就算成了。

Linux 服务器上操作稍微讲究一些。因为 ES 不允许用 root 用户直接跑，需要单独建一个用户，比如：

bash复制useradd esuser
chown -R esuser:esuser /opt/elasticsearch-7.17.18
su esuser
cd /opt/elasticsearch-7.17.18/bin
./elasticsearch

如果是云服务器，内存紧张的话，先把 jvm.options 里 -Xms4g、-Xmx4g 改成 1g 或 2g，不然会启动失败或者太卡。注意，7.x 仍然需要修改 /etc/sysctl.conf 里的 vm.max_map_count=262144，用 sysctl -p 使其生效，否则会报 max virtual memory areas vm.max_map_count [65530] is too low，这个坑可以说是每个 ES 新手都会撞上。

还有一个很实用的经验：远程调试时把 network.host: 0.0.0.0 配上，discovery.type: single-node 也建议加上，避免单节点模式下因为选举问题导致启动异常。生产环境当然不能这么干，但本地开发和测试环境这么配置很省心。

2.2 Spring Boot 与 Spring Data Elasticsearch 版本矩阵

这是最容易翻车的一环。我这边整理了一份实操验证过的对应关系，覆盖 Spring Boot 2.x 时代主流的 ES 7.x 版本：

这里有两点要特别说明。第一，不要轻易自己覆盖 starter 里的 spring-data-elasticsearch 版本，因为你可能改了版本后 API 对不上。第二，Spring Boot 3.x 对应的是 Spring Data Elasticsearch 5.x，已经不兼容 ES 7.x 的老接口了。所以如果你的项目在 Spring Boot 2.7.18 上，直接用它内置的 starter 版本，连 ES 7.17，是我个人最推荐的生产组合，稳定省心。

2.3 application.yml 连接配置与验证

配置文件千万别写成老旧的 spring.data.elasticsearch.cluster-name、cluster-nodes 格式，那是 TransportClient 时代的玩艺，7.x 用 starter 已经不认识它了。正确姿势是 spring.elasticsearch.rest 前缀：

yaml复制spring:
  elasticsearch:
    rest:
      uris:
        - http://192.168.1.10:9200
        - http://192.168.1.11:9200
      connection-timeout: 10s
      socket-timeout: 30s
      username: elastic
      password: changeme

如果你是单机本地调试，uris 写一个地址就够了。千万别把 ES 地址写成 localhost:9200 忘了 http:// 前缀，这个低级错误会导致解析异常。socket-timeout 建议给足，某些聚合查询或大范围搜索耗时比较长，默认的 10 秒很容易超时。

配置完以后，怎么验证真的连上了？一个简单粗暴的办法是启动 SpringBoot 项目时做一个 ApplicationRunner：

java复制@Component
public class EsHealthRunner implements ApplicationRunner {

    private final ElasticsearchOperations operations;

    public EsHealthRunner(ElasticsearchOperations operations) {
        this.operations = operations;
    }

    @Override
    public void run(ApplicationArguments args) {
        boolean alive = operations.indexOps(IndexCoordinates.of("health-check"))
                .exists();
        System.out.println("ES connection check: " + alive);
    }
}

如果你从这里就能看到返回 true 或 false，说明客户端已经正常连上 ES 集群了。反之，你会看到 NoNodeAvailableException 或者各种 connect timeout，那就得回头检查地址、防火墙和认证配置了。

3. 核心代码实现：实体、映射与查询

环境搞定，进入写代码环节。Spring Data Elasticsearch 的基本套路是三步走：定义实体模型、写 Repository 接口、在 Service 里注入使用。但实际项目里你还会碰到索引自动创建的问题、动态字段映射、复杂 Boolean 查询、分页排序这些绕不开的场景，这一章我把这些核心动作拆开讲。

3.1 @Document 与 @Field 注解：实体类即索引映射

先看一个典型的商品索引实体：

java复制@Data
@Document(indexName = "product", createIndex = true)
public class ProductIndex {

    @Id
    private String id;

    @Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart")
    private String title;

    @Field(type = FieldType.Keyword)
    private String brand;

    @Field(type = FieldType.Double)
    private BigDecimal price;

    @Field(type = FieldType.Integer)
    private Integer stock;

    @Field(type = FieldType.Keyword, fielddata = true)
    private String category;

    @Field(type = FieldType.Text, fielddata = true)
    private String description;

    @Field(type = FieldType.Date, format = DateFormat.date_optional_time)
    private LocalDateTime createTime;

    @Field(type = FieldType.Nested)
    private List<SkuAttr> attrs;
}

@Document(indexName="product") 指定索引名，createIndex=true 表示如果索引不存在，项目启动时会根据实体类自动创建。真正决定字段类型的是 @Field。这里有几个过来人才懂的细节：

Text 类型会分词，适合做全文搜索；Keyword 类型不分词，适合做精确匹配、排序、聚合。很多人一开始把所有字符串都标成 Text，结果发现“品牌聚合”这种需求完全查不出来，就因为 Keyword 才能作为聚合桶。我上面的例子把 brand 设成 Keyword，就是避免踩这个坑。

analyzer 和 searchAnalyzer 最好分开配置。比如索引用 ik_max_word 做最细粒度切分，让召回率更高；搜索时用 ik_smart 让 query 更精准，避免大词带来的噪音。这里默认你已经在 ES 集群里装好了 IK 分词插件，没装的话会在索引创建时报 analyzer [ik_max_word] not found。

实体类里加一个 @Id 标记，对应 ES 文档的 _id。注意，如果你用 createIndex = true 并且服务已经连上集群，ES 会自动做映射；但自动创建的索引，字段类型可能不符合预期，比如把 LocalDateTime 映射成 text。所以生产环境更稳妥的做法是：手动管理 mapping，关闭自动创建，这个我在 3.4 节单独说。

3.2 Repository 接口：框架级方法名查询

定义完实体，接下来是最有 Spring Data 特色的部分——Repository。看这个接口：

java复制public interface ProductRepository extends ElasticsearchRepository<ProductIndex, String> {

    List<ProductIndex> findByTitleAndPriceBetween(String title, BigDecimal minPrice, BigDecimal maxPrice);

    Page<ProductIndex> findByBrand(String brand, Pageable pageable);

    List<ProductIndex> findByTitleContaining(String keyword);
}

方法名 Spring Data 会解析成 ES 查询：And 对应 bool 的 must，Between 对应 range 查询，Containing 对应模糊匹配。这功能用起来很爽，但有两个必须注意的边界：

第一，ES 的全文搜索 Containing 底层是分词匹配，而不是 SQL 里的 like。如果用户搜索“手机”，在 ik_max_word 分词下单独一个“手”字都能命中标题。要精准地做“短语匹配”，得用 @Query 注解或者 Native 查询，单纯靠方法名搞不定。

第二，嵌套对象查询用方法名是不现实的。比如上面实体里的 attrs 是 Nested 类型，你要查“规格=黑色 的 256G 版本”，方法名根本没法表达这种同时作用于同一嵌套文档的逻辑。这时候就需要 ElasticsearchOperations 出场。

3.3 ElasticsearchOperations：复杂查询的正确打开方式

业务查询稍微复杂一点，我建议直接放弃方法名查询，改用 ElasticsearchOperations。先看一个典型的 bool 查询例子：

java复制@Service
public class ProductSearchService {

    private final ElasticsearchOperations operations;

    public ProductSearchService(ElasticsearchOperations operations) {
        this.operations = operations;
    }

    public Page<ProductIndex> search(ProductSearchParam param) {
        NativeSearchQueryBuilder builder = new NativeSearchQueryBuilder();
        BoolQueryBuilder bool = QueryBuilders.boolQuery();

        if (StringUtils.hasText(param.getKeyword())) {
            bool.must(QueryBuilders.matchQuery("title", param.getKeyword()));
        }
        if (StringUtils.hasText(param.getBrand())) {
            bool.filter(QueryBuilders.termQuery("brand", param.getBrand()));
        }
        if (param.getMinPrice() != null || param.getMaxPrice() != null) {
            bool.filter(QueryBuilders.rangeQuery("price")
                    .gte(param.getMinPrice())
                    .lte(param.getMaxPrice()));
        }

        builder.withQuery(bool);
        builder.withPageable(PageRequest.of(param.getPage(), param.getSize()));
        builder.withSort(Sort.by(Sort.Direction.DESC, "createTime"));

        SearchHits<ProductIndex> hits = operations.search(builder.build(), ProductIndex.class, IndexCoordinates.of("product"));
        return new PageImpl<>(hits.getSearchHits().stream()
                .map(SearchHit::getContent)
                .collect(Collectors.toList()),
                PageRequest.of(param.getPage(), param.getSize()),
                hits.getTotalHits());
    }
}

这么写的好处是：过滤条件放 filter 子句而不放 must 子句，这是 ES 性能优化里很关键的一个习惯。filter 子句结果会被缓存，不参与相关性打分；must 会计算分数。对于品牌过滤、价格区间这种业务筛选，压根不需要影响排序，所以放 filter 最合理。

还有一个实用技巧：withPageable 分页深度过大时会触发 ES 的 Result window is too large 错误，默认 from+size 不能超过 10000。如果你要做“深分页”导出全量数据，一方面调大 max_result_window 指标，另一方面更合理的方案是使用 search_after。Spring Data 里可以用 SearchAfterRequest 自行实现，不过大部分业务场景控制页数在 100 页以内就够了，不必过度设计。

聚合也是 ElasticsearchOperations 的强项。比如统计每个类目下的商品数量：

java复制NativeSearchQueryBuilder builder = new NativeSearchQueryBuilder();
TermsAggregationBuilder agg = AggregationBuilders.terms("category_count")
        .field("category")
        .size(10);
builder.withAggregations(agg);
SearchHits<ProductIndex> hits = operations.search(builder.build(), ProductIndex.class, IndexCoordinates.of("product"));

然后从 hits.getAggregations() 里取出 ParsedStringTerms 对象，遍历 bucket 拿到 key 和 docCount。这一招在做后台数据看板的时候非常实用，不用再把数据拉出来自己数，其性能比 Java 内存按组统计快几个数量级。

3.4 用 IndexOperations 接管索引，别完全依赖自动创建

@Document(createIndex = true) 确实省事，但真实项目里我一般不这么干。原因有两个：一是生产环境索引 mapping 需要经过评审，字段类型写错以后再改就麻烦大了；二是自动创建时给 String 类型默认的映射是 text+keyword 并存，这在某些场景会导致不必要的索引膨胀。

所以更规范的做法是把自动索引关掉，启动时手动初始化：

java复制@Component
public class EsIndexInitializer {

    private final ElasticsearchOperations operations;

    public EsIndexInitializer(ElasticsearchOperations operations) {
        this.operations = operations;
    }

    @PostConstruct
    public void initIndex() {
        IndexOperations indexOps = operations.indexOps(ProductIndex.class);
        if (!indexOps.exists()) {
            indexOps.create();
            indexOps.putMapping(indexOps.createMapping());
        }
    }
}

createMapping() 会根据实体类上的注解生成 Mapping JSON。这样索引的创建、映射的更新都在代码里可见，部署到新环境时不用手动敲命令。

不过要提醒的是，ES 的 mapping 一旦写入，字段类型就不可修改了。只能新增字段，不能把 keyword 改成 text。所以设计阶段一定要想清楚哪些字段需要分词、哪些需要聚合。我遇到过最痛的教训，是把一个“商品标签”字段定义成 Text，后续想拿它做 filter 聚合，死活出不来正确结果，最后只能重建索引重新导数据，白白花了两个通宵。

4. 数据写入与业务落地的完整方案

实体和查询都写好了，但真实项目不是写完 CRUD 就完事。ES 本身不是数据源，它更像是数据库的“读模型”，如何把业务库的数据同步过去、如何保证数据一致性，是真正考验工程能力的地方。这一节我梳理一下我们项目里踩过坑以后沉淀下来的方案。

4.1 数据同步三种策略：全量、双写与监听

最简单的方案是定时全量同步。每天凌晨跑一个 Job，把 MySQL 里的商品表全查一遍，然后全量写入 ES，或者按更新时间增量更新。这适合数据量不大、实时性要求不高的系统，比如管理后台的搜索列表。优点就是简单粗暴，出问题了大不了全部重建一次。

实时性要求再高一些，就得上应用双写。业务代码里在写 MySQL 的同时，顺手把索引文档写进 ES。这个方案优点是实时性最强，ES 6.x/7.x 的写入延迟本来就是秒级，用户体验最好；缺点也不小，双写失败会导致数据不一致，必须引入重试和补偿机制。没有消息队列的话，这种双写就是一锤子买卖，事务边界非常脆弱，用户下单成功但 ES 没写入，搜索就少了一条，客户投诉就来了。

更推荐的方案是监听 MySQL binlog 或者用 MQ 异步同步。把数据变更信息发到 MQ，另起一个消费者专门负责写 ES。MySQL 这边做增删改，MQ 消息发出去，ES 写入出错就重试，重试还失败就进死信队列告警。这个方案解耦了业务库和搜索引擎，也是大多数中大型项目的标配。如果你的项目里本来就有 RocketMQ 或 RabbitMQ，优先考虑这种模式。

4.2 批量导入性能调优：真的别一条条写入

很多新人上来就 repository.save(entity)，写一万条数据要等半天。ES 的每一次写入请求都涉及网络往返、分片 refresh，一条条写简直是灾难。批量操作要用 bulk API，Spring Data 提供了 BulkOperations：

java复制public void batchImport(List<ProductIndex> products) {
    BulkOperations bulkOperations = operations.bulkOps(IndexCoordinates.of("product"));
    for (ProductIndex product : products) {
        bulkOperations.add(
                IndexQuery.builder()
                        .withId(product.getId())
                        .withObject(product)
                        .build()
        );
    }
    bulkOperations.bulkIndex();
}

如果你是初次接触，可能觉得这不就是把循环往里 add 一下吗？但框架底层会把这些操作合并成一个或者几个 bulk 请求发到 ES，性能差异巨大。实测下来，500 条一个大批次写入，单条耗时从几十毫秒降到几毫秒，全量导入一万条数据差不多几秒钟完成。

bulkOperations.bulkIndex() 执行完以后，还要注意刷新策略。ES 默认是每秒刷新一次，写入成功后立刻去搜索，可能查不到刚写进去的数据，但这其实不算 bug，而是 ES 的近期一致性设计。如果你必须在写后立即可见，可以在 bulk 之后调用：

java复制operations.indexOps(ProductIndex.class).refresh();

但这个操作有性能代价，每次写入都强制刷新，吞吐量会明显下降。业务上通常只在“写完就通知用户去查”的场景用，比如订单支付成功后立刻搜索订单详情。

4.3 更新和删除的一致性问题，比写入更隐蔽

更新的麻烦在于，ES 没有跨文档事务，你只能先 get 后 update，或者用 script 局部更新。Spring Data 里 repository.save() 对已存在的文档是全量覆盖，如果实体类里某个字段是 null，也会被写入为空值，跟 MySQL 的 update 语义差远了。

所以我的经验是：ES 的文档更新，尽量设计成“幂等整条覆盖”。也就是说，索引文档存的不应该是数据库表原样字段，而是一个面向查询视图组装好的宽表结构。更新时直接 set 新的文档，不纠结哪些字段改了。这样语义最简单，也不会出“只改了标题却没改品牌分词”的幺蛾子。而删除方面，ES 7.x 默认没有物理删除，只是把文档标记为 deleted，在 segment 合并后才会真正释放空间，平时不用过度担心这个，定期做 force merge 就够了。

还有一个细节：删除文档之后立刻执行 count 查询，数据量可能还是包含旧值，这也跟 refresh 有关。接口层如果需要删除后立即可见，同样记得强制 refresh，否则自动化测试会给你上眼药。我见过团队写集成测试，删除成功断言列表为空，经常偶发失败，查了半天才发现是 refresh 的问题。

5. 常见问题与排查实录

最后这章，我把自己在多个项目里撞过、从线上熬夜修过的典型问题整理一下。这些问题在官方文档里可能只有一句话，但实际处理起来真的会让人崩溃。

5.1 启动连不上 ES：从 NoNodeAvailableException 查起

最经典的错误就是：

bash复制org.elasticsearch.client.transport.NoNodeAvailableException: None of the configured nodes are available

遇到这个，不要慌，按优先级排查：第一，确认服务端 ES 进程是否真在运行，curl http://localhost:9200 看看能不能返回 JSON；第二，确认 Spring 配置的 uris 有没有写错，很多低版本 starter 不认识新版配置，导致默认连 localhost:9300 去了；第三，确认是不是认证问题，如果 ES 开了安全认证，username/password 填错，表面报错是连接不上，但实际是 401 Unauthorized；第四，服务器防火墙是否放开了 9200 端口；第五，跨网络访问时，ES 配置里的 network.host 是不是只绑定了 127.0.0.1。

还有一种情况很隐蔽：版本自带的传输协议不兼容。比如服务端是 ES 8.0，客户端 starter 却是 4.4.x，底层走 REST 协议可能还勉强能通，但如果走了旧 transport 协议直接就报版本冲突。这种错误信息里往往会带上版本号，一眼就能定位，所以版本表的对应关系一定要时刻记着。

5.2 写入慢的排查：别急着甩锅给 ES

“ES 写入慢”这个问题被问过无数次，判断到底是磁盘问题、还是集群问题、还是代码问题，可以从几个指标看。

先看服务端指标。用 curl http://localhost:9200/_cat/indices?v 看索引大小和文档数，用 curl http://localhost:9200/_cat/thread_pool/write?v 看写线程池队列。如果 write 线程池总是处于 active 且 queue 爆满，说明写入压力已经很大了，要么加节点，要么改成批量写入。

再看磁盘 I/O 指标。如果用的是云服务器，iostat -x 1 看看 %util 是否长期在 90% 以上，await 如果超过几十毫秒，那磁盘大概率就是瓶颈。ES 的写入要落 translog、要写 Lucene 数据文件，对磁盘随机写入要求很高。之前我遇到过一台机械硬盘的服务器，ES 写入量一大 CPU 才 10%，但 iostat 显示磁盘一直满负荷，最后换了 SSD 后写入速度直接翻了几倍。

最后回到代码层面：是不是没用 bulk？是不是每写一条都强制 refresh？是不是 Mapping 里字段数量爆炸？有个项目因为业务每加一个属性就加一个字段，最后索引有三百多个字段，写入性能自然趴窝。ES 不是一个放着随便设计的存储，字段数量、分词器选择、doc_values 开启情况都会直接影响写入速度。

5.3 异常速查表与最后的避坑锦囊

最后再送几个锦囊。第一，索引规划阶段提前想好 mapping 和分词器，后面改索引的成本堪比换数据库。第二，全部用 ElasticsearchOperations 写复杂的 Native 查询，Repository 方法名只用来做最简单的单条件查询。第三，不要随手开启 fielddata，内存管不住，线上 OOM 就是这么来的。第四，如果你要在 SpringBoot 里做 PDF 上传、XSS 过滤这种全局过滤器，建议在过滤器里就统一清洗文本，别等脏数据进了 ES 再想着怎么洗，那就晚了一步。

根据我个人的经验，SpringBoot 集成 ES 7.x 用 starter 这波操作，只要跨过版本匹配这一关，日常开发效率真的高很多。但这套组合打死也不是“零成本”，它逼着你提前思考索引模型、数据同步和查询规范。技术选型没有万能的银弹，不过对于绝大多数业务团队来说，spring-boot-starter-data-elasticsearch 确实是最省心、最不容易出幺蛾子的落地方式之一。