以下是对您提供的博文内容进行深度润色与结构重构后的技术文章。整体风格更贴近一位资深搜索平台工程师在技术社区的自然分享：逻辑清晰、语言精炼、有实战温度，无AI腔调；摒弃模板化标题与刻板段落，代之以真实问题驱动、层层递进的叙述节奏；所有技术点均嵌入上下文语境中讲解，并强化了“人在工具中如何思考、如何试错、如何验证”的过程感。
当 Kibana 里的查询突然变慢：一个日志搜索性能优化的真实切片
上周三下午四点十七分，运维告警弹窗跳出来：“logs-*索引 P99 查询延迟突破 2.1 秒”。不是偶发抖动，是持续 5 分钟以上的阶梯式抬升。而就在两小时前，同一个查询在 Dev Tools 里还稳定在 300ms 内。
这不是第一次。但这次我决定不急着改参数、不盲目扩节点——而是打开 Kibana 的Profile API 面板，把那个看似普通的match查询，一帧一帧拆开来看它到底卡在哪。
这背后，是一整套被可视化工具“托住”的 DSL 优化实践：从布尔逻辑怎么组织才不白算分，到为什么range放filter里就快了六倍，再到service.name字段明明写了term却缓存不命中——原来它压根不是keyword类型。
我们不讲抽象原则。只说你在 Kibana 里真正会遇到的问题、看到的数据、点下的按钮，和改完之后监控曲线怎么回落。
你写的bool，ES 其实悄悄重排了执行顺序
很多人以为bool就是把几个条件“并列写出来”，比如：
{ "bool": { "must": [ { "match": { "message": "timeout" } } ], "filter": [ { "range": { "@timestamp": { "gte": "now-1h" } } } ] } }看起来很干净。但 Lucene 不吃这套“表面秩序”。
它会在执行前做一件关键的事：按计算成本重排子句优先级。
-filter和must_not是“零打分”操作，Lucene 直接用位图（RoaringBitmap）算交集，快且可缓存；
-must和should要调Similarity模块，算 TF-IDF、长度归一化、协调因子……CPU 密集；
- 所以 ES 会自动把filter提前执行，一旦匹配失败，后面整个
