ElasticSearch _search API 默认不返回版本的原因及性能影响咨询

这是个很务实的问题——Elasticsearch的这个设计其实是从性能优化和核心需求优先级出发的，咱们拆开来详细说：

一、为什么默认不返回文档版本号？ #

• 减少无效数据传输：对绝大多数普通查询场景来说，版本号完全是冗余信息。比如你只是搜索商品详情、日志内容这类只读场景，根本不需要知道文档的版本。默认不返回能显著降低每个响应的payload大小，尤其是批量返回大量文档时，这点节省会直接减少网络带宽消耗，也能让客户端更快解析响应。
• 聚焦核心场景需求：Elasticsearch的核心能力是搜索与分析，版本号的主要作用是乐观并发控制——比如你在更新或删除文档时，用version参数来避免并发冲突。这类写操作场景属于进阶需求，不是读查询的默认刚需。把版本号做成可选返回，能让_search API的默认行为更轻量化，贴合大多数用户的日常使用习惯。
• 避免误用与误解：如果默认返回版本号，很容易让新手误以为它是全局唯一的稳定标识，但实际上Elasticsearch的版本号是单文档的递增计数器，不同文档的版本号没有可比性。默认隐藏能减少这类不必要的误解和误用。

二、返回版本号会带来性能损耗吗？ #

答案是几乎可以忽略，原因如下：

• 无额外计算/IO开销：版本号是文档元数据的一部分，Elasticsearch在存储文档时就已经把它持久化了。查询时获取版本号只是多读取一小块现成的元数据，不会触发额外的计算、磁盘IO或者索引操作——就算你不请求版本号，Elasticsearch内部也已经持有这个值了。
• 仅极端场景有微小影响：只有当你一次性返回数万甚至数十万条文档时，额外传输的版本号数据才会带来一点点网络层面的开销，但这种场景本身就不建议用普通_search查询，而是应该用滚动查询（scroll）或者深度分页来处理，所以实际中几乎不会成为性能瓶颈。
• 类比其他元数据：这和你请求返回_id、_index这类元数据是一个道理，都是现成的信息，只是多了几个字节的响应内容而已，完全不会影响查询的核心性能。

内容的提问来源于stack exchange，提问作者jhilden