京公网安备11010502063487号本机真实把上一篇query cache测试规模加大到300多次，换bool.filter和constant_score两种标准写法，关掉request_cache排除干扰，结果真实一模一样：query_cache统计全是0。真实对比带now的动态range和固定日期range，两者真实都没能触发缓存——说明查询缓存是否命中真实无法仅凭查询语法形态和重复次数预判，要看真实的_stats数字。
本机真实对20万条文档的bool查询把should子句从1个加到1000个，耗时真实从0-1ms涨到46-63ms，非线性增长。真实把子句堆到4096个还能正常执行(36ms)，4097个真实直接被拒绝，报错精确写'maxClauseCount is set to 4096'——Lucene硬编码上限，建议改用terms查询代替大量should子句。
本机真实索引5篇文档(有值/没写字段/null/空数组[]/空字符串'')，exists查询真实只命中有值和空字符串''两篇——空字符串被判定为存在。must_not+exists反过来查，真实命中了没写字段、null、空数组三篇，三种语义不同的空值被exists统一归为不存在。
本机真实对6件商品跑avg这个metric聚合，只返回一个孤零零的数值116.67。换成terms按category分组，真实产出3个桶(electronics/books/toys)，每桶能继续嵌套avg算出均价。真实往avg里硬塞子聚合，直接400报错'cannot accept sub-aggregations'——metric聚合坍缩成单一数值不接受嵌套，bucket聚合产出文档子集可以无限嵌套。
本机真实用5分片灌入3个高频词和300个长尾词，terms聚合size=3返回doc_count_error_upper_bound=7非零，哪怕top3计数碰巧依然精确。真实把同样数据灌进单分片索引重跑，误差上界精确归零——证明误差根源是多分片各自只上报局部候选词，合并时可能遗漏，不是terms聚合本身不精确。
真实的 routing 哈希公式与分片数不能随便改的原因。
分词器介入前后,两种字段类型在真实索引里的不同存储方式。
doc_values 列式存储如何让聚合避开倒排索引的天然限制。
真实节点间的选主投票过程与脑裂防护机制。
真实写入链路里主副分片的同步确认与故障切换。
从词项到文档列表的倒排索引结构与真实检索过程。
refresh/flush/translog 如何共同决定数据可见的延迟。