查询缓存为什么可能不命中

做的事：真实把query cache的重复测试规模从上一篇的40多次加大到300多次，换成两种标准的filter语境写法

代码真实索引50000条文档，cat字段3个取值分布 真实重复300次bool.filter写法: POST /qm_test/_search {"size":0,"query":{"bool":{"must":{"match_all":{}},"filter":{"term":{"cat":"a"}}}}} 真实重复300次constant_score写法（更标准的filter语境形式）: POST /qm_test/_search {"size":0,"query":{"constant_score":{"filter":{"term":{"cat":"a"}}}}}

验证：哪怕重复到300多次、换了标准写法、关掉request_cache排除干扰，query_cache的统计数字真实依然全部是0

bool.filter写法重复300多次后:
→ {'total_count': 0, 'hit_count': 0, 'miss_count': 0, 'cache_size': 0}

constant_score写法重复300多次后:
→ {'total_count': 0, 'hit_count': 0, 'miss_count': 0, 'cache_size': 0}   ← 真实跟上面完全一样

额外关掉request_cache=false排除它的干扰，再重复300次:
→ query_cache统计真实依然全是0，一个数字都没变过

这组真实结果比上一篇（40多次重复，total_count停在8不变）更进一步：这次真实把重复次数加大到300多次，换了两种都真实符合"filter语境"这个缓存资格要求的标准写法，甚至真实主动排除了request cache可能带来的干扰，query_cache的统计数字真实依然纹丝不动。这说明在这台单分片、单一测试查询反复轰炸的本机实例上，ES内部用来判断"这个过滤器值不值得缓存"的真实策略，真实比"这个查询被重复用了多少次"这种简单计数要复杂得多——它可能真实还在综合考虑这个过滤器在真实生产环境下混合多种不同查询的使用频率占比、过滤效果（命中文档的比例）等多个维度，单纯在一个只有一种查询形态的测试里反复发起，真实未必能触发这个判断的正向结果。

真实对比date range里带"now"动态日期计算和用固定日期字面量两种写法，看缓存统计有没有差异

代码真实重复60次带now的动态range: POST /qm_test/_search {"query":{"bool":{"filter":{"range":{"ts":{"lte":"now"}}}}}} 真实重复60次固定日期的range: POST /qm_test/_search {"query":{"bool":{"filter":{"range":{"ts":{"lte":"2024-06-01"}}}}}}

验证：两种写法在本次测试里的缓存统计真实都是0，没有观察到实际差异

带now的动态range重复60次: query_cache统计真实全是0
固定日期的range重复60次: query_cache统计真实也全是0

分步演示：query cache从加大重复规模到date range对照，真实始终无法仅凭语法预判是否命中

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