在数据量较小时，SQL中的LIKE配合百分号可以完成关键词匹配，但当单表记录超过百万级别、查询涉及多个字段时，这种方案会触发全表扫描，CPU和IO迅速飙升，响应时间从毫秒级退化到秒级。全文检索依赖倒排索引，将文档分词后建立词项到文档ID的映射，检索时直接定位词项，避免了逐行扫描。Elasticsearch基于Lucene构建，支持分布式、近实时搜索，Spring Boot项目通过spring-boot-starter-data-elasticsearch可以快速接入。

本文从依赖配置、索引映射、查询构建、高亮展示和性能调优五个环节展开，重点说明text与keyword字段的设计差异、NativeSearchQuery的高亮与分页用法，以及深分页场景下from+size的短板和替代方案。读完可以直接搭建一个可用的全文检索服务，也能避开常见配置误区。

一、环境准备与依赖配置

使用Spring Boot整合Elasticsearch之前，需要先准备一个可用的Elasticsearch实例。本地开发环境可以直接用Docker启动单节点，执行命令后容器默认监听9200端口，无需额外安装。生产环境则建议使用三节点以上的集群，通过统一网关或IP列表对外提供访问。需要注意Spring Boot版本与Elasticsearch客户端的兼容性问题，较新的Spring Boot 3.x系列通常要求使用8.x版本的Elasticsearch，而Spring Boot 2.x系列则与7.x版本匹配更加稳定。版本错配会出现客户端连接异常、索引创建失败等问题，因此在引入依赖之前务必核对兼容矩阵。

项目依赖配置十分简单，在pom.xml中加入spring-boot-starter-data-elasticsearch即可，它会自动引入Elasticsearch Java客户端、Jackson序列化以及Spring Data仓储支持。不需要手动添加RestHighLevelClient的单独依赖，因为新版本已经统一由ElasticsearchClient接管。配置文件中需要指定连接地址、用户名和密码，如果本地ES未开启安全认证，可以省略认证信息。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>

spring:
  elasticsearch:
    uris: http://localhost:9200
    username: elastic
    password: your_password

配置完成后，Spring Boot会在启动时自动创建ElasticsearchClient实例，并在需要时注入到服务类中。如果需要自定义连接超时、证书校验或请求压缩等参数，可以通过配置类进一步调整，但常规场景下默认配置已经足够。值得一提的是，测试阶段不要频繁手动修改ES中的数据，应尽量通过程序构建索引和插入文档，保证索引结构可重复创建。

二、实体映射与索引设计

Spring Data Elasticsearch使用注解将Java对象映射为索引中的文档。@Document注解标注在实体类上，通过indexName指定索引名称，同时可以设置分片数和副本数。@Id用于标记文档唯一标识，@Field则用于描述字段类型、是否分词、是否可索引等元数据。一个常见误区是认为所有字符串字段都适合用默认的text类型，实际上text类型会经过分词器切分，适合全文检索，而keyword类型保持原样，适合精确匹配、排序和聚合。商品名称、描述等需要模糊匹配的字段应配置为text，而商品分类、状态、标签等字段应配置为keyword。

中文场景下分词器的选择同样关键。Elasticsearch默认的标准分词器会将中文逐字切分，检索效果不佳。需要为text字段指定ik_max_word或ik_smart等中文分词器，前者做细粒度切分，召回率更高，后者做粗粒度切分，索引体积更小。索引中已经存在的数据不会因为修改映射而自动更新，因此字段类型和分词器必须在创建索引前明确设计。如果后续发现字段类型不合理，只能通过创建新索引并迁移数据的方式解决。

import org.springframework.data.annotation.Id;
import org.springframework.data.elasticsearch.annotations.Document;
import org.springframework.data.elasticsearch.annotations.Field;
import org.springframework.data.elasticsearch.annotations.FieldType;
@Document(indexName = "product")
public class Product {
    @Id
    private String id;
    @Field(type = FieldType.Text, analyzer = "ik_max_word")
    private String name;
    @Field(type = FieldType.Keyword)
    private String category;
    @Field(type = FieldType.Double)
    private Double price;
    @Field(type = FieldType.Date, format = {})
    private String createTime;
    // 省略getter和setter
}

对于日期类型，可以根据实际数据格式设置format属性，避免JSON解析时类型转换失败。数值类型如Double、Long等无需特殊配置，Elasticsearch会自动识别并建立适合范围查询的索引结构。实体类中不建议包含额外的业务逻辑，保持纯粹的字段映射即可，复杂计算逻辑应放在Service层处理。

三、实现全文检索：Repository与复杂查询

最简单的检索方式是继承ElasticsearchRepository接口，声明一些方法名，Spring Data会自动根据方法名生成查询。例如findByNameContaining表示按名称包含匹配，findByCategoryAndPriceBetween表示按分类和价格区间过滤。这种方式适合条件固定、逻辑简单的查询场景，代码量极少，但缺点是查询语义受限于方法名规则，无法灵活控制分词、权重和相关性算分。

复杂检索场景需要使用ElasticsearchOperations或ElasticsearchRestTemplate，结合NativeSearchQuery来构建查询。NativeSearchQueryBuilder可以自由组合matchQuery、boolQuery、rangeQuery等查询条件，并附加分页、排序和过滤条件。以商品搜索为例，用户输入关键词“华为手机”，需要对商品名称和描述字段做多字段匹配，同时过滤掉下架商品，并按价格升序排列，返回第1页共20条结果。

public List<Product> searchProducts(String keyword, String category, int page, int size) {
    NativeSearchQueryBuilder builder = new NativeSearchQueryBuilder();
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    boolQuery.must(QueryBuilders.multiMatchQuery(keyword, "name", "description"));
    if (category != null && !category.isEmpty()) {
        boolQuery.filter(QueryBuilders.termQuery("category", category));
    }
    boolQuery.filter(QueryBuilders.termQuery("status", "on_sale"));
    builder.withQuery(boolQuery);
    builder.withPageable(PageRequest.of(page, size));
    builder.withSort(SortBuilders.fieldSort("price").order(SortOrder.ASC));
    SearchHits<Product> searchHits = elasticsearchOperations.search(builder.build(), Product.class);
    return searchHits.getSearchHits().stream().map(SearchHit::getContent).collect(Collectors.toList());
}

multiMatchQuery会同时在多个字段中查找关键词，并综合各字段得分进行排序。如果希望商品名称命中时权重更高，可以为不同字段设置boost值。过滤条件使用filter而非must，因为filter不参与相关性算分，执行速度更快。分页通过PageRequest控制页码和每页条数，但页码过深时会面临性能问题，这一点在第五部分详细分析。排序可以按价格、销量、创建时间等字段进行，但排序字段必须设置为keyword或数值类型，否则会因分词导致排序结果不符合预期。

四、高亮与聚合：提升搜索体验

用户在搜索框输入关键词后，期望在结果列表中看到匹配片段被高亮显示。Elasticsearch支持在查询时指定高亮字段，并返回带标签包裹的片段。在Spring Data Elasticsearch中，需要通过HighlightBuilder构建高亮规则，为需要高亮的字段设置前置标签和后置标签，默认是和。查询执行后，从SearchHit中读取高亮字段内容，如果存在则替换原始字段值用于前端渲染。使用高亮时要注意，高亮字段必须是text类型并配置了分词器，否则无法正确生成片段。

HighlightBuilder highlightBuilder = new HighlightBuilder();
highlightBuilder.field(new HighlightBuilder.Field("name").preTags("<em>").postTags("</em>"));
builder.withHighlightBuilder(highlightBuilder);
SearchHits<Product> hits = elasticsearchOperations.search(builder.build(), Product.class);
for (SearchHit<Product> hit : hits) {
    Map<String, List<String>> highlightFields = hit.getHighlightFields();
    List<String> nameFragments = highlightFields.get("name");
    if (nameFragments != null && !nameFragments.isEmpty()) {
        hit.getContent().setName(nameFragments.get(0));
    }
}

聚合分析是全文检索的另一个常见需求。例如在商品搜索结果页侧边栏展示各分类下匹配到的商品数量，方便用户进一步筛选。Elasticsearch的聚合能力可以一次请求同时返回查询结果和聚合统计，避免多次调用。使用AggregationBuilders.terms按category字段进行桶聚合，结果中每个桶的key是分类名称，docCount是该分类下的文档数量。聚合字段必须是keyword类型，否则会将分词后的每个词项作为一个桶，统计结果失去意义。

builder.addAggregation(AggregationBuilders.terms("category_count").field("category"));
SearchHits<Product> hits = elasticsearchOperations.search(builder.build(), Product.class);
Aggregations aggregations = hits.getAggregations();
if (aggregations != null) {
    Terms terms = aggregations.get("category_count");
    for (Terms.Bucket bucket : terms.getBuckets()) {
        String categoryName = bucket.getKeyAsString();
        long count = bucket.getDocCount();
        System.out.println(categoryName + ": " + count);
    }
}

高亮和聚合可以同时使用，两者互不影响。不过需要注意的是，高亮信息存储在单独的highlightFields中，聚合结果存储在aggregations中，解析时要分别处理。实际项目中可以将这两部分数据封装成单独的ResultVO返回给前端，使接口结构清晰，也方便前端统一渲染。

五、性能调优与避坑指南

深分页是Elasticsearch中最容易被忽视的性能陷阱。from+size方式在查询时需要先检索出全部命中的文档，再跳过前面的记录，返回指定页。当from值达到几万甚至几十万时，内存占用和响应时间会显著增加，甚至导致节点内存溢出。解决深分页问题的常用方式是使用search_after或scroll。search_after通过上一次返回结果的排序值定位下一页起始点，避免了跳过大量文档，适合顺序翻页场景，但不支持直接跳转到任意页。生产环境中如果用户只需要浏览前几页，可以限制最大页码，对于超过限制的请求返回空结果或提示缩小搜索范围。

索引刷新频率也会直接影响写入性能。Elasticsearch默认每秒将内存中的新数据刷新到可搜索状态，这种近实时特性在搜索场景下很有必要，但批量导入时频繁刷新会拖慢写入速度。大批量数据初始化时，可以将refresh_interval暂时设置为30秒或更久，或者直接关闭自动刷新，写入完成后再恢复默认值。同时，increase replica数量可以提高搜索吞吐量，但会增加写放大和存储成本，具体副本数需要根据集群规模和业务读写比例综合权衡。

还有一个常见的误区是频繁修改索引映射。已经创建好的索引，字段类型、分词器等核心属性不可直接修改，只能通过reindex迁移数据。因此在设计阶段要尽可能想清楚字段的使用方式，预留一些扩展字段，或者使用动态映射配合合理的dynamic模板，避免后期因为映射调整而付出数据迁移的代价。连接池和客户端连接数也要设置合理值，过大的连接池会占用大量网络资源，过小则在高并发下出现等待超时。通常单个Spring Boot实例的连接数控制在200以内即可满足大部分场景。

实际项目中还可以借助压测工具模拟高并发搜索，观察Elasticsearch节点的CPU、堆内存和磁盘IO情况，及时调整JVM堆大小和分片分配策略。海量数据全文检索不是搭建完成就结束了，持续监控和调优才能保持稳定高效。