本机真实存了带mustache默认值语法的search template,价格区间1000-2000真实正确过滤出price=1500的文档。真实不传min_price/max_price时反转section语法正确回退成0/100000。真实做注入安全测试:故意打断JSON结构的恶意query_string真实被安全转义成普通字符串值,没有任何match_all注入发生。
本机真实灌5万条文档,from=10000真实被硬性拒绝,报错明确写默认上限10000。调大限制后from=0稳定1ms,from=49990真实15-28ms,慢了15到28倍——因为分片要排出from+size条候选再丢弃。真实用search_after在同样深度查询,稳定回到1ms,跟第一页完全一样快。
本机真实灌2万条文档,n字段每值重复200次。只按n排序翻页,search_after:[0]真实直接跳到n=1,195条同样n=0的文档被静默跳过,查询不报任何错误。真实加唯一id_tiebreak字段做复合排序后重新验证,search_after真实精确停留在n=0组内继续翻页,一条不漏。
本机真实打开PIT后插入新文档并刷新,同一个PIT查询真实依然只看到打开那一刻的10条,不带PIT的常规搜索真实能看到全部11条。真实关闭PIT后再查询,直接404 search_context_missing_exception,证明PIT需要显式维护生命周期。
本机真实用scroll分30批取完3万条文档,总耗时0.122秒。真实发现scroll首次响应的total是精确值30000(eq),普通搜索默认被截断成10000(gte)——scroll真实绕开了这个上限。真实用search_after做同样任务对比,耗时0.106秒,跟scroll性能相当但更轻量,印证官方现在更推荐PIT+search_after。
本机真实发现/_search/scroll续传接口结构上没有query字段,scroll_id真实绑定了打开那一刻的具体查询。真实重用较早的scroll_id不是报错也不倒回,而是从当前游标位置继续。真实对比PIT:同一个pit id真实可以配合两条完全不同的查询(n<10和n>=4990)分别使用,都成功执行且保持同一快照一致。
本机真实灌100万条全部匹配同一查询的文档,track_total_hits=true精确计数真实耗时2-5ms;false和默认行为(上限10000提前停止)真实都稳定1ms。精确计数需要真实遍历全部匹配文档,耗时随匹配总数增长而增长,而提前停止不受匹配总数影响。
本机真实对10万条文档验证terminate_after:简单match查询加不加几乎无差别,terminated_early依然false。换成每篇500次sqrt循环的script_score查询,不加耗时136ms,加terminate_after=100骤降到1ms,terminated_early变true。真实又发现跟track_total_hits:true同用时terminate_after被完全忽略,依然精确数完全部10万条。
本机真实索引6件商品(3色各2件),query的bool filter限定color=red:聚合桶真实也跟着只剩red。换成post_filter限定同样条件:返回文档真实仍只有2件red,但聚合桶真实blue/green/red三色都在各2件——post_filter真实完全不影响聚合,只收窄最终展示结果,正是电商按颜色筛选分面搜索的真实需求。
本机真实搜'elasticsearch performance'不设min_score命中3篇(得分1.63/0.41/0.31),加min_score=0.5后只剩1.63那篇,hits.total精确收窄为1。真实验证min_score也会收窄聚合桶,这跟上一篇post_filter不影响聚合的结论形成直接对照——min_score在聚合之前生效,post_filter在聚合之后生效。
本机真实索引3位作者共6篇文章,不加collapse返回全部6条,加collapse(author)后真实每位作者只剩1条但hits.total依然是6。真实对text字段用collapse直接报错不支持,只能用keyword等doc_values字段。真实搭配inner_hits把每组折叠掉的次优文章重新取回来。
本机真实搜'quick',基础排序词频高的文档排第一(0.167)。加rescore用match_phrase加权5倍、window_size=10覆盖全部时,排名真实翻转,短语匹配更精确的文档反超排第一(1.405)。真实把window_size收窄到1后,排名完全没翻转——第二名没被纳入窗口,哪怕按rescore_query分数更高也没有翻身机会。