Elasticsearch 6.8 升级到 7.10 时，查询语法兼容性需重点关注类型移除、客户端兼容及新查询特性。首先，7.x 版本移除了映射类型（_type），查询路径不再包含类型名，需调整 API 调用，例如从 index/type/_search 改为 index/_search。其次，客户端版本需匹配，高版本客户端可能无法访问低版本集群，建议升级 rest-high-level-client。此外，7.10 引入了 Interval 间隔查询、Distance feature 查询等新语法，可替代部分旧查询但需注意性能开销。建议升级前使用迁移 API 检查废弃用法，重建索引以确保兼容性，并测试客户端连接及查询 DSL 的正确性，避免服务中断。同时注意分页查询改用 PIT 替代 scroll，以提升深度分页性能。
谈谈 ES 6.8 到 7.10 的功能变迁 (3)- 查询方法篇
上一篇咱们了解了 ES 7.10 相较于 ES 6.8 新增的字段类型，这一篇我们继续了解新增的查询方法。Interval 间隔查询：功能介绍 Interval 查询，词项间距查询，可以根据匹配词项的顺序、间距和接近度对文档进行排名。主要解决的查询场景“创建一个多搜索词匹配的查询，同时保留搜索词的顺序”,比 match phrase 更加符合需求场景，查询方法使用比 span 查询更简单。ES 后续版本想用 interval 查询逐步替代 span 查询。注意事项 规则组合 可以使用 prefix、wildcard、fuzzy 等规则 通过设置 max_gaps 和 ordered 参数，可以控制词项间的最大间隙和顺序要求。性能考虑 间隔查询比简单的词项匹配更消耗资源 嵌套规则越多，性能开销越大 建议合理使用 maxGaps 参数限制间距 使用限制 只能用于 text 字段 不支持跨字段查询 不支持对数值类型字段使用 Distance feature 查询 功能说明 时间/地理距离特性查询，该查询用于查找更接近被查询日期和地理位置的结果。日期和位置分别是声明为 date 和 geo_point 数据类型的字段。返回结果的字段值不需要完全等于被查询值，而是按照给定日期或给定位置的进度算分，越是接近被查询值，在相关性得分中被评为更高。字段类型要求 日期字段必须是 date 类型，地理位置字段必须是 geo_point 类型 不支持其他类型的距离计算 评分机制 距离越近，得分越高 使用 boost 参数调整权重 可以与其他查询组合使用 性能考虑 地理距离计算较为耗费资源，建议使用合适的索引优化地理查询，比如：考虑使用地理网格索引提升性能 Pinned 查询 功能说明 实现对某些文档的置顶功能，使用存储在_id 字段中的文档 ID 来标识升级或“固定”的文档。此功能通常用于引导搜索者查找精选的文档，这些文档在搜索的任何"organic"匹配项之上被提升。当查询中有排序时，pinned 查询失效。使用限制 不能与自定义排序一起使用 置顶文档必须存在于索引中 最多支持 100 个置顶文档 排序规则 置顶文档按照 ids 数组中的顺序排序 organic 查询结果按照相关性得分排序 置顶文档始终在 organic 结果之前 PIT 查询 功能说明 Point intime 查询是一个轻量级的视图，根据保留周期保留 PIT 查询发生时数据的状态，用于不同条件的深度分页查询。scroll 滚动搜索及其上下文与查询内容绑定。这意味着编写一个查询，添加一个滚动参数，来自这个查询的响应数据就会保持一致。不同的查询内容则会产生不同的 scroll 上下文，资源使用就会相对紧张。（来自 2025 年 2 月 24 日的资料）
Elasticsearch 版本升级实践、注意事项
从官方文档看可以发现两个大版本升级需要关注到具体的版本，比如想从 5.x 版本升级到 7.x 版本，就必须先升级到 6.8 版本，再从 6.8 升级到 7.x 版本。检查是否可以升级 1. 版本号确认 2. 通过 API 检查是否存在过期的用法 # ES6.x GET/_xpack/migration/deprecations?filter_path=index_settings # ES7.x GET/_migration/deprecations?filter_path=index_settings 关注其中的 critical 的整改项; 一键获取完整项目代码 3. 可以查看 segment 信息，检查是什么版本的 lucene(也就可以知道 ES 版本) 创建的，例如 5.x 创建的索引，即使已经升级到 6.8 版本，想要升级到 7.17，依然需要重建索引。异常 如果出现不兼容的情况，ES 节点无法启动。注意事项 1. 客户端 ES 不同版本的客户端，可以说是非常乱了，抛开非官方推荐的 client(jest、bboss 等),依然有很多不兼容的地方。这里简单列一些结论:(仅包括 rest-high-level-client) 7.5 的 client 可以访问 6.8 的集群 6.8 的 client 可以访问 7.5 的集群 6.8.23 的 client 的版本可以访问 7.17.5 的集群 7.17.5 的 client 不能访问 6.8.5 集群 ("message":"Elasticsearch exception [type=exception, reason=Content-Type header [application/vnd.elasticsearch+json; compatible-with=7] is not supported]") 一键获取完整项目代码 2.type ES 的 type 也是比较尴尬的地方，带有历史债的场景，改动相对不那么平滑。ES6.8 创建带 type 的 index，直接升级到 7.17，可以通过 带 type/_doc 来查询、写入 # ES6PUT 一个索引 PUT zmc { "mappings": { "type1": { "properties": { "aa": { "type":"keyword" } } } } } # POST 一条数据 POST zmc/type1 { "aa":"test" } GETzmc/_search # 升级到 7.17 # 执行，可以查到结果 GETzmc/type1/_search { } # 执行，可以查到结果 GETzmc/_search { } # 执行，不可以查到结果 GETzmc/_doc/_search { } # 可以写入 POST zmc/type1（截至 2022 年 12 月 15 日）
Elasticsearch 升级 7.x 版本后，我感觉掉坑里了!
首先我们可以在 pom.xml 中修改 SpringBoot 依赖的版本为 2.3.0; 代码语言:javascript AI 代码解释 然后在项目的 External Libraries 中搜索 elasticsearch，可以发现 elasticsearch-7.6.2.jar 这个依赖; 然后打开其中的 MANIFEST.MF 文件，通过 jar 包中的 X-Compile-Elasticsearch-Version 属性，我们可以找到兼容的 Elasticsearch 版本号为 7.6.2; 之前还有试过两个版本 6.2.2 版本和 7.4.0 版本，发现与 SpringBoot 2.3.0 都有兼容性问题，所以选择合适的版本很重要！还有一点值得注意的是，如果你使用了中文分词器 (IK Analysis),也要选择对应的版本 7.6.2，对于使用 Kibana 和 Logstash 也是如此。遇到的问题 选择好了合适的 Elasticsearch 版本后，接下来我们来讲讲升级版本遇到的问题了！在 application.yml 中，原来我们用来配置 Elasticsearch 访问路径和集群名称的配置已经不建议使用了; 取而代之的是直接配置 Elasticsearch 的 rest 访问地址; 代码语言:javascript AI 代码解释 其实最大的问题还是 ElasticsearchTemplate 已经过时了，不建议使用了，之前复杂的数据操作用到了它; 推荐使用的是 ElasticsearchRestTemplate，这大概就是修改 application.yml 中那两个配置的原因了，修改为使用 ElasticsearchRestTemplate 后，我们可以发现原来 ElasticsearchTemplate 的 query() 方法已经没有了; 可以使用 ElasticsearchRestTemplate 的 search() 方法来代替，原来的复杂查询将有以下改进; 代码语言:javascript AI 代码解释 // 使用 ElasticsearchTemplate 进行复杂查询 returnelasticsearchTemplate.query(searchQuery,response ->{LOGGER.info("DSL:{}",searchQuery.getQuery().toString());returnconvertProductRelatedInfo(response);});// 使用 ElasticsearchRestTemplate 进行复杂查询 SearchHits
一、版本不是随便选的：主版本变更 = 系统级重构
先泼一盆冷水:Elasticsearch 的主版本升级，本质上是一次架构重写。很多人以为 7.17 → 8.0 只是数字变了，其实它带来的变化比你想象中剧烈得多：安全模块默认开启 TLS 加密; 节点间通信协议彻底更换 (Zen2 → Coordination Engine); 不再支持 TCP 9300 端口 (Transport 模块被移除); 所有索引格式强制升级; 用户权限模型重构。这些都不是“改几个配置就能搞定”的事。这就像你要把一辆燃油车改成纯电驱动——发动机可以保留吗？不能。所以 elasticsearch 官网 明确规定：禁止跨主版本跳跃升级。比如你不能从 6.8 直接跳到 8.0，中间至少得经过 7.17 这个“过渡站”。 ✅ 正确路径:6.8 → 7.17 → 8.0 ❌ 错误做法:6.8 → 8.0 (直接报废) 为什么一定要走中间版本？因为 7.17 是最后一个支持旧数据格式的版本，也是唯一能同时读取 6.x 数据并写入 8.x 兼容结构的桥梁。（消息于 2026 年 1 月 19 日发布）
FAQ
升级后原有的 type 查询会失效吗？
是的，7.x 版本移除了 mapping type，查询路径中不能再包含类型名，需改为 index/_search 形式。
客户端版本不匹配会有什么后果？
高版本客户端可能无法访问低版本集群，报错 Content-Type header 不支持，建议客户端版本与集群版本保持一致或兼容。