9.3 查询性能优化：让命中更快

9.3 查询性能优化：让命中更快

本节摘要：查询慢了不要瞎调参数，先诊断：慢查询日志圈出嫌疑人，画像接口拆解耗时构成，指标定位瓶颈层（IO、CPU、线程池）。诊断之后是五刀：filter 化吃缓存、限制扇出、深分页换游标、字段瘦身、索引与分片重规划。本节把第 3、5、8 章的零件组装成一套可复用的提速方法论。

慢下来的时刻

一、诊断三步：先找嫌疑人，再验伤，后定位

第一步开慢查询日志，把"慢"变成名单：

PUT tickets/_settings
{
  "index.search.slowlog.threshold.query.warn": "2s",
  "index.search.slowlog.threshold.query.info": "500ms",
  "index.search.slowlog.threshold.fetch.warn": "1s"
}
​

超过五百毫秒的查询写进慢日志，带着完整的请求体与分片级耗时——名单有了。第二步对头号嫌疑人做画像，看时间花在哪一段：

GET tickets/_search
{
  "profile": true,
  "query": { "match": { "title": "退款" } }
}
​

profile 响应（节选）：
"query" 段 title 的 rewrite 与 collect 各占多少毫秒
"fetch" 段 source 加载与高亮各占多少
直接指出 瓶颈在查询期还是取回期
​

第三步看节点指标：线程池拒绝数涨说明查询排队长（并发超载）、IO 等待高说明在扫冷数据（缓存不命中）、CPU 高而 IO 低说明在算（脚本、深归并、大 bool）。三步下来，慢的层与量都有数，才轮到动刀。

诊断流程图

二、五刀详解

第一刀：filter 化与缓存。 5.2 讲过 filter 上下文不算分、结果可缓存——同条件重复查询近乎零成本。检查所有"匹不匹配"型条件（状态、时间范围、租户、标签）是否还留在 must 里，搬进 filter 是零风险高回报的第一刀。第二刀：限制扇出。 一次查询扇出到所有涉及分片（5.1 的两阶段），扇出越少归并越轻：带 routing 只查相关分片（写入侧同 routing 前提下）、时间范围查询只点名相关日期索引（按天滚动的索引名做过滤）、禁用无谓的跨索引通配。第三刀：翻页换姿势。 深翻页的候选爆炸（5.3 的推导）改成游标方案；导出场景检查有没有人拿 from 加 size 一万一页硬翻——这是集群公敌。第四刀：字段与响应瘦身。 取回期占比高时，源过滤只取要展示的字段、高亮字段限量、size 别虚高；列表页三十条足够，别一次取两百"备用"。第五刀：索引重规划。 前四刀无效说明瓶颈在结构：冷热数据混在一个索引里互相拖累——按时间拆索引、冷索引进生命周期管理迁到低配存储；分片过小过碎或过大过沉，回到 8.2 的规划原则重排。第五刀成本最高（要重建迁移），所以放最后。

三、一次提速的完整过程

背景：运营反馈工单搜索偶发五六秒，高峰尤甚；慢日志一开，名单里三条查询反复出现。操作：画像显示取回期占七成——响应里带着完整 _source（每条三 KB）加五个字段的高亮；同时查询期 bool 里挂着租户过滤与时间范围的 must。动刀：源过滤只取列表页四字段、高亮限两字段；must 里的两个条件搬进 filter；size 从五十降到二十。结果：三条查询全部回到两百毫秒内，集群取回线程池排队消失。解读：两刀都是"减法"——少取、少算、少扇出，优化查询最常见的形态不是加什么，而是减什么。变式：改完仍慢的第四条查询走的是跨三十天通配搜索，拆成按天索引名列表后（查询端生成最近七天），扇出减七成，也回到可接受区间。

常见坑：跳过诊断直接抄网上的调优清单——加大缓存、改线程数、换打分模式。参数调优是最后一厘米，结构与查询形态才是主体；顺序反了，等于不问伤在哪就开药。

关键直觉：慢查询的账单分三栏——查得多（扇出广）、算得多（评分与脚本）、搬得多（源与高亮）。诊断就是算清三栏各占多少，优化就是砍最贵的一栏。

考核与自测

考核知识点清单

动手验证：把慢日志打开

慢查询日志是诊断的原料库，两条设置就能开工：

PUT tickets/_settings
{ "index.search.slowlog.threshold.query.warn": "1s",
  "index.search.slowlog.threshold.fetch.warn": "200ms" }
​

超过一秒的查询期与两百毫秒的取回期会分列两本日志，每条带请求体原文。攒一天名单，按耗时排序取前三条下刀——诊断流程的第一步就此落地，第五章的画像参数则在每条下刀前给出分期证据。

易错点补充

• 优化一次就收工：查询形态随业务演化，慢日志要常开常看，优化是例行的减法不是一次性冲刺。
• 只盯着最慢的一条：榜单第二第三名往往是同构查询，一刀下去批量受益，先看共性再看个性。
• 优化后不做基线对比：改前改后各压一轮同条件查询，延迟分位与吞吐都有了再下结论，凭体感宣布胜利无法复现。
• 把缓存命中率当唯一功劳簿：缓存救得了一时救不了新查询，命中率高的同时仍慢，说明瓶颈不在查询期，回账单重新分期。