Elasticsearch范围过滤性能差异排查：foo.x查询远慢于bar.a

1. 稀疏字段的获取阶段额外开销 #

foo.x是极度稀疏字段，仅存在于数百条文档中，在1亿总文档中占比极低。Elasticsearch执行查询分为两个核心阶段：

• 查询阶段（Query Phase）：通过倒排索引快速定位到匹配gte:3,lte:5的文档，这一步耗时并不高；
• 获取阶段（Fetch Phase）：需要从所有匹配的候选文档里，过滤出实际包含foo.x字段的条目，同时加载_source中的元数据。由于大部分候选文档都没有foo.x字段，ES要逐一检查文档的字段存在性，还要从磁盘读取并解析大量不包含目标字段的_source数据，这带来了巨大的IO和CPU开销。

而bar.a存在于数万条文档中，匹配文档占比高，获取阶段的过滤和_source加载开销自然小很多，整体耗时因此更低。

2. 缓存机制的适配性问题 #

Elasticsearch的查询缓存、字段数据缓存对高频访问、数据分布均衡的字段更友好：

• 对于foo.x这种极稀疏字段，大部分查询结果都是空值或不匹配，缓存条目复用率极低，几乎无法通过缓存降低后续查询耗时；
• bar.a的匹配文档数多，缓存的结果更有价值，后续查询能直接命中缓存，大幅减少重复计算和IO操作。

3. _source=false的性能提升逻辑 #

当关闭_source时，ES跳过了加载并解析_source文档的步骤，仅需要确认查询阶段得到的匹配文档有效性（这一步已完成）。此时无需处理大量不包含foo.x的文档的_source数据，获取阶段开销几乎消失，所以耗时骤降至20ms以内。但这也导致无法返回元数据，不符合业务需求。

关于尝试方案无效的补充说明 #

• 强制合并段：合并段主要解决段数量过多导致的查询遍历开销，但无法减少稀疏字段在获取阶段的字段存在性判断和_source加载开销，因此对性能无改善；
• 改为float_range类型：float_range字段针对的是存储范围值的场景，而你的需求是对普通float字段做范围查询，改类型并未解决稀疏字段的核心问题，反而可能引入额外的索引结构开销，因此无效。

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