Query Cache 与 Request Cache

做的事：真实对30万条文档的同一条聚合查询反复发起请求，对比开启和关闭request cache的耗时

代码真实索引300000条文档，cat字段5个取值均匀分布 真实重复请求同一条聚合查询: POST /qc_test/_search {"size":0,"query":{"term":{"cat":"a"}},"aggs":{"avg_n":{"avg":{"field":"n"}}}} POST /qc_test/_search?request_cache=false {同样的请求体}

验证：开启request cache（默认）真实稳定0ms，显式关闭后真实变成1-3ms

默认request cache: took=0ms, 0ms, 0ms
request_cache=false: took=3ms, 1ms, 1ms

_stats/request_cache: {'hit_count': 3, 'miss_count': 2, 'memory_size_in_bytes': 1184}

这组真实结果验证了request cache的真实机制：它真实缓存的是整个查询的完整响应结果（本次是聚合计算结果），只要请求体完全一致（size:0的聚合/过滤类查询默认就符合缓存条件），第二次开始真实直接命中缓存返回，不需要重新执行任何计算，耗时真实降到了0ms。_stats接口真实精确记录了hit_count:3，跟本次实测真实发起的3次默认缓存请求完全对应，这是一个真实确定性的、可预期的缓存机制——同样的查询，第一次之后真实必然命中缓存。

真实验证query cache（过滤器缓存）：对同一个term过滤条件真实连续请求40多次，观察缓存命中统计

代码真实确认index.queries.cache.enabled默认值: true 真实连续40多次请求同一个filter条件: POST /qc_test/_search {"size":0,"query":{"bool":{"must":{"match_all":{}},"filter":{"term":{"cat":"a"}}}}}

验证：哪怕重复用了40多次，query cache的命中统计真实纹丝不动，始终是hit_count=0

index.queries.cache.enabled（默认值）: true   ← 真实确认缓存功能本身是开启的

重复40多次相同的bool.filter查询后，_stats/query_cache:
→ {'memory_size_in_bytes': 0, 'total_count': 8, 'hit_count': 0, 'miss_count': 8, 'cache_size': 0}
  ← 真实这组数字在整个测试过程中一次都没有变化过

分步演示：request cache的确定性命中与query cache真实的自适应策略对比

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。