计划：
- 先确定集群类型与指标路由规则，避免 Premium/Serverless 作用域取错
- 将给定时间窗转换为 evidence 收集所需的时间戳范围
- 采集该时间窗内 CPU、GC、TopSQL/慢查询、热点与资源饱和等证据
- 基于证据链给出最可能根因、影响判断与处置建议根因最可能是：业务读请求在该时间窗内显著增压，并且存在单条 SQL digest（`43D2B9...`，来自 `dh_user_action_logs` 相关统计查询）在 TiKV 单实例上形成 CPU 热点，带动 TiKV gRPC 延迟升高与 TiDB CPU 饱和。

关键证据链：
- 资源/基础设施排除：EBS 节流与磁盘 IO 利用率均为 `CLEAR`，组件数量稳定、日志无 ERROR/WARN（`evidences/evidence_summary_for_agent.txt`#L6, #L190-#L201, #L257-#L261）
- CPU 现象成立：TiDB 出现 CPU 饱和（`db-tidb-0/1/2/5` 峰值约 `89%~90%` of 64 cores），同窗 TiDB P99 latency 峰值升至 `0.218~0.25s`（`evidences/evidence_summary_for_agent.txt`#L39-#L65）
- 热点与归因：Gate 检测到 TiKV gRPC P99 多实例热点（最高 `db-tikv-29 peak=0.102s`，对比 peer_avg `~0.019s` 达 `5.3x`），并标记“Query hotspot：digest `43D2B9...` 在 `db-tikv-44` 上 `cpu_pct=63.9%`”（`evidences/evidence_summary_for_agent.txt`#L7, #L45-#L54）
- 不是 GC 导致的 TiDB CPU：Go GC 频率/耗时/暂停整体为 normal/warning 级别，未见与 CPU 饱和同级别的异常（`evidences/evidence_summary_for_agent.txt`#L90-#L125）
- 负载强度背景：该时间窗 Select 语句速率均值约 `67k/s`、峰值约 `78k/s`（`evidences/evidence_summary_for_agent.txt`#L156-#L172）

因果链：
- `dh_user_action_logs` 相关统计查询（digest `43D2B9...`）在 TiKV 单实例上形成 CPU 热点 → TiKV gRPC P99 拉升并出现多实例热点 → TiDB 执行/等待成本增加且部分 TiDB 实例 CPU 饱和 → 端到端查询 P99 上升（峰值 ~0.25s）

影响判断：
- 严重性：High（TiDB 多实例达到 >85% CPU 利用率，且 TiDB P99 明显上升；同时 TiKV gRPC P99 出现 2x~5x 热点）

处理建议：
1. 立刻止血：对 digest `43D2B9...` 对应业务接口做限流/降级/缓存（优先），避免继续在单 TiKV 上放大热点。
2. SQL/索引方向：拉取该 digest 的完整 SQL 与执行计划（本次 evidence 未包含其 decoded plan），重点检查 `dh_user_action_logs` 的过滤条件列是否有匹配的联合索引、是否存在大范围扫描/高 fanout 的聚合计数；必要时通过 SQL binding 固化更优访问路径。
3. 热点缓解：若热点与 key-range 相关，评估对热点表进行分区/打散写入键（或调整业务查询的时间范围/维度），降低单 Region/单 Store 集中访问。
4. 复盘验证：用相同“同一时刻的前一日/前两日”窗口做对比采集，确认该 digest 的 CPU 占比与 TiDB CPU 饱和在时间线上同步（用于把“偶发抖动”与“可复现负载问题”区分开）。