Elasticsearch Runtime Fields性能及搜索阶段计算逻辑咨询

1. 搜索请求执行过程中Runtime Fields的计算逻辑 #

Runtime Fields是ES 7.11版本推出的读时计算字段，不会固化写入索引文件，仅在查询阶段按需触发计算，具体执行逻辑如下：

• 仅查询请求中显式引用的Runtime Fields会被计算，未引用的索引级Runtime Fields不会产生任何计算开销。引用场景包括过滤条件、聚合规则、_source返回字段配置三类。
• 计算在分片查询阶段执行，针对当前分片待处理的文档，运行你预先写好的Painless脚本，从_source或者其他已存储的内置字段中取值处理，生成对应字段的临时值。
• 单次查询请求的runtime_mappings节点中定义的临时Runtime Fields，优先级高于索引层面预先配置的同名字段，会覆盖索引级的字段定义。

2. Runtime Fields的过滤执行逻辑与性能影响 #

过滤执行逻辑 #

首先明确答案：不会先对全量文档计算所有索引Runtime Fields再进入过滤阶段。
ES查询优化器会优先执行成本更低的普通索引字段过滤逻辑，通过倒排索引快速缩小符合条件的文档范围，仅对过滤后剩余的文档，计算查询用到的Runtime Fields，再执行针对Runtime Fields的过滤、聚合操作。
只有当整个查询的过滤条件全部是Runtime Fields时，才会需要扫描当前分片的所有文档，逐行计算对应Runtime Fields后再做过滤。

性能影响程度 #

Runtime Fields的性能损耗和三个因素直接相关：

• 计算前剩余的文档量：如果前置普通字段过滤已经把待处理文档缩小到千级别以内，Runtime Fields的计算开销几乎可以忽略；如果需要扫描百万级以上的全量文档计算，性能会比普通索引字段过滤低1~2个数量级。
• 脚本复杂度：仅做简单的日期格式转换、字符串拼接、数值计算的脚本开销很低，涉及复杂正则匹配、多字段嵌套逻辑、外部数据调用的脚本开销会成倍上涨。
• 引用的Runtime Fields数量：单次查询引用的Runtime Fields越多，总计算开销越高。

日常使用建议：高频过滤、聚合的字段优先做索引固化，Runtime Fields更适合临时查询、低频统计、字段规则需要频繁调整的场景。

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