知其然,知其所以然
Elasticsearch 2026-10-01

Highlight 高亮的实现方式

本机真实验证fvh高亮器没配term_vector直接400报错。80词短文档上plain反而略快于fvh(8-13ms vs 10-14ms),不符合常见说法;换1500词长文档重测,fvh真实快了一倍多(12ms vs 25-29ms),但存储真实多了约50%(7.8mb vs 5.2mb)。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Search As You Type

本机真实用search_as_you_type字段看到自动生成的_2gram('quick brown'/'brown fox')、_3gram('quick brown fox')子字段。真实用bool_prefix搜'quick br',命中两个完整词的文档得分2.18,只命中一个词的0.18。真实验证打字早期阶段'qui'时两篇候选文档得分完全相同,体现随输入逐步精确的设计。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Completion Suggest 与普通前缀查询的区别

本机真实灌5万条数据对比:completion suggester预热后稳定0ms,prefix查询稳定2ms且额外算出7196条总命中数——completion走内存FST不算总数,prefix走常规打分路径要统计。真实验证completion的fuzzy参数:不开时错别字'aple'0候选,开fuzziness=1后5个apple候选全部正确召回。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Phrase Suggest 与 Term Suggest

本机真实对'quik browm'跑term suggest:独立给两个词各自正确推荐quick/brown。真实跑phrase suggest默认配置,最意外发现完全正确的'quick brown'压根没出现在候选里,因为max_errors默认值1限制了只能同时纠正1个词。真实调到max_errors=2后,'quick brown'才以最高分0.076排第一。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Search Template 参数化查询

本机真实存了带mustache默认值语法的search template,价格区间1000-2000真实正确过滤出price=1500的文档。真实不传min_price/max_price时反转section语法正确回退成0/100000。真实做注入安全测试:故意打断JSON结构的恶意query_string真实被安全转义成普通字符串值,没有任何match_all注入发生。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

from + size 分页的深分页问题

本机真实灌5万条文档,from=10000真实被硬性拒绝,报错明确写默认上限10000。调大限制后from=0稳定1ms,from=49990真实15-28ms,慢了15到28倍——因为分片要排出from+size条候选再丢弃。真实用search_after在同样深度查询,稳定回到1ms,跟第一页完全一样快。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

search_after 深分页

本机真实灌2万条文档,n字段每值重复200次。只按n排序翻页,search_after:[0]真实直接跳到n=1,195条同样n=0的文档被静默跳过,查询不报任何错误。真实加唯一id_tiebreak字段做复合排序后重新验证,search_after真实精确停留在n=0组内继续翻页,一条不漏。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Point In Time 与 search_after

本机真实打开PIT后插入新文档并刷新,同一个PIT查询真实依然只看到打开那一刻的10条,不带PIT的常规搜索真实能看到全部11条。真实关闭PIT后再查询,直接404 search_context_missing_exception,证明PIT需要显式维护生命周期。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Scroll 查询适合什么场景

本机真实用scroll分30批取完3万条文档,总耗时0.122秒。真实发现scroll首次响应的total是精确值30000(eq),普通搜索默认被截断成10000(gte)——scroll真实绕开了这个上限。真实用search_after做同样任务对比,耗时0.106秒,跟scroll性能相当但更轻量,印证官方现在更推荐PIT+search_after。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

Scroll 与 Point In Time 的区别

本机真实发现/_search/scroll续传接口结构上没有query字段,scroll_id真实绑定了打开那一刻的具体查询。真实重用较早的scroll_id不是报错也不倒回,而是从当前游标位置继续。真实对比PIT:同一个pit id真实可以配合两条完全不同的查询(n<10和n>=4990)分别使用,都成功执行且保持同一快照一致。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

track_total_hits 对性能的影响

本机真实灌100万条全部匹配同一查询的文档,track_total_hits=true精确计数真实耗时2-5ms;false和默认行为(上限10000提前停止)真实都稳定1ms。精确计数需要真实遍历全部匹配文档,耗时随匹配总数增长而增长,而提前停止不受匹配总数影响。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-01

terminate_after 提前终止查询

本机真实对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万条。

Elasticsearch 真实验证 动画演示
京ICP备2026067502号-1京公网安备11010502063487号