- 先把时间窗转换成诊断脚本/指标查询需要的时间戳格式，并确认集群类型以便做正确的指标路由
- 拉取该时间窗内的 expensive query 告警上下文（TopSQL/慢日志、资源指标、关键事件）
- 交叉验证“最可能根因”假设（SQL/执行计划变化、热点/锁/统计信息、资源瓶颈等）并形成证据链
- 输出影响判断与可执行的处置/长期优化建议根因判断我按这个顺序做：先确认集群类型与时间窗 → 看 expensive query 告警对应的热点形态（是否是单实例/单 SQL 驱动）→ 用 TopSQL/热点检测/线程 CPU/基础设施与日志做交叉验证 → 给出“最可能根因”与可落地的处置建议。

**Root Cause**: 该时间窗内出现“单条业务查询（digest=A778…）驱动的 TiKV 热点”，导致 TiKV 某实例 CPU/线程与 gRPC 延迟异常，从而触发 expensive query 告警。

**Key Evidence**:
1. 热点检测直接给出 Query hotspot：digest `A778DFEE...` 在 `db-tikv-38` 上 cpu_pct=68.2%（同窗内 TopSQL 归因到单 digest 级别的主导消耗）。
2. 同时存在实例侧异常：TiKV gRPC P99 热点 `db-tikv-21` 0.051s，peer_avg 0.016s，3.3x（符合 expensive query 触发时“TiKV 服务端处理/排队变慢”的形态）。
3. TiKV 线程 CPU 以 `unified_read` 与 `grpc` 为主（如 `db-tikv-38 grpc peak 4.6983 cores`，`unified_read peak 5.687 cores`），与“读路径压力 + 单查询放大”一致。
4. 排除基础设施/系统性故障：EBS throttle severe=0、disk_io_util max=0；TiDB/PD/TiKV 日志 ERROR/WARN 为 0；组件数量无变化。

**Causality**: 单 digest 查询在特定 TiKV 实例上占用主要 CPU → TiKV `grpc/unified_read` 线程繁忙、gRPC P99 抬升（并出现实例热点）→ 该 SQL 的执行成本/等待上升 → expensive query 告警触发（影响该类查询及依赖其链路的业务请求）。

**Ruled Out / Not Relevant**: 本窗内无 EBS/磁盘瓶颈、无组件重启/报错日志；TiDB 整体 P99 很低且 TiDB CPU 利用率不高，说明不是“全局 TiDB 层”问题；GC Pause P99 有 warning 但缺少与告警形态的主导相关性证据，暂不作为主因。

**Severity**: Medium（热点集中在特定 TiKV/特定 digest，倾向于“部分查询/部分请求”受影响；未见全局 TiDB P99 失控或基础设施退化）。

**Recommendation**:
1. 立即止血：针对 digest `A778...` 对应 SQL（`dh_message_user_params` + `dh_message_setting_currency` + `dh_message_setting` 的多表 LEFT JOIN + 多条件过滤 + LIMIT），优先检查/补齐能覆盖过滤与关联键的索引（重点围绕 `a.useridx/a.site_code/a.message_id`、`b.currency/b.message_id`、`c.id/c.send_time/c.publish_status` 的组合与前缀顺序），避免在 TiKV 上产生大量无效读与 join 放大。
2. 低风险缓解：对该 SQL 增加“稳定计划”措施（如通过 SQL Binding 固化更优访问路径/连接顺序），避免在高并发下偶发走到更重的路径。
3. 补全证据以验证索引/计划结论：本窗内未抓到该 digest 的 slow query 样本（因此没有 decoded_plan）。建议在业务侧拿到原始 SQL 后执行一次 `EXPLAIN ANALYZE`；或适当扩大时间窗/临时下调慢日志阈值以捕获该 digest 的慢样本，再做精确的“瓶颈算子/est-act 偏差/索引命中”分析。
4. 复盘与预防：对 `db-tikv-38` 的热点做 region/leader 分布与访问倾斜检查（若该表/索引存在 key 分布偏斜，可能需要业务侧打散或通过调度手段缓解实例倾斜）。