Elasticsearch中查询多索引是否比查询单索引慢

直接查询单索引transaction-2000的速度略优于带timestamp过滤条件查询别名transaction的方式，二者性能不会完全一致，但在索引数量不多的常规场景下，差距极小，业务层几乎感知不到。

性能差异的核心来源 #

二者的核心差异来自查询前期的分片路由剪枝阶段的额外开销，正常配置下不会出现查询别名时扫描所有年度索引全量数据的情况：

• 当你直接指定transaction-2000查询时，Elasticsearch 协调节点只会把请求转发给该索引下的所有分片，直接进入查询执行流程，没有额外判断成本。
• 当你查询别名transaction时，协调节点首先要把请求扇出到别名关联的所有年度索引的所有分片，先执行can match（可匹配性判断）阶段：每个分片所在节点会基于内存中维护的字段min/max统计值，检查本地分片的timestamp取值范围是否和查询的2000年时间范围有重叠，如果完全没有重叠就直接返回空响应，跳过后续的索引扫描、聚合、排序等重操作。
  这个扇出请求、等待各分片返回可匹配性判断结果的过程，就是别名查询多出来的固定开销，且这部分判断是纯内存操作，本身成本极低。

影响性能差距大小的因素 #

性能差距不是固定值，和你的集群配置、索引规模直接相关：

• 如果你的别名下只关联了3-5个年度索引，can match阶段的开销基本在毫秒级，完全可以忽略。
• 如果你的别名下关联了10个以上的年度索引，扇出请求的网络往返成本、节点判断成本会线性升高，这时候直接指定单索引的性能优势会更明显。
• 如果你的timestamp字段没有设置为date类型、或者单年度索引里混入了其他年份的脏数据，会导致can match阶段无法准确剪枝，查询会真的扫描所有索引的分片，此时别名查询性能会比直接查单索引差一个数量级以上。

实操建议 #

• 如果业务代码里可以很方便地根据查询时间范围计算出对应的年度索引名称，直接指定目标索引查询是性能最优的方案，没有任何额外开销。
• 如果不想在业务层维护索引路由逻辑，希望统一用别名查询，可以给每个年度索引配置固定的范围过滤别名，或者在7.14及以上版本开启时间序列索引配置、显式标注每个索引的时间起止边界，能让ES在路由阶段直接跳过不相关索引，把别名查询的额外开销降到几乎为0。

注意：不存在“别名查询一定比单索引查询慢很多”的情况，只要字段映射配置正确，ES的分片剪枝机制不会真的扫描无关索引的业务数据，不用过度担心性能问题。

内容的提问来源于stack exchange，提问作者Joey Yi Zhao