- 先确认集群类型/路由规则（Premium/Serverless/Dedicated），避免拿错指标范围  
- 读取知识库里的“常见误判清单”，把需要额外校验的点前置成约束  
- 在给定时间窗内采集关键证据（指标/事件/TopSQL/慢查/日志摘要），对齐“17:47 左右高延迟”现象  
- 基于证据链收敛到最可能根因，并给出影响判断与处置建议（短期止血 + 长期修复）  

- 集群类型为 Dedicated；该时间窗（2026-04-07T08:47:00Z–10:42:00Z）内的核心现象是：`db-tidb-0` 出现 CPU 打满（97%）并成为明显慢点，同时 `db-tikv-1` 存在单条 SQL digest 的 CPU 热点，整体表现为 TiDB 查询 P99 明显抬升、业务侧在“17:47 左右”（与 08:47Z 对齐）感知高延迟/接近不可用。

Root Cause: 高并发业务查询 + 单实例承压（`db-tidb-0` 在窗口内 CPU 长时间接近打满，且 TopSQL 显示主要 CPU 消耗集中在少数 digests），叠加窗口内 TiDB 进程重启/实例数波动导致流量/执行压力更集中到 `db-tidb-0`，触发高延迟与可用性下降。

Key Evidence:
1. Hotspot/Gate：检测到 `db-tidb-0` CPU saturation，峰值 `7.8/8 cores (97% utilization)`，属于“CPU 打满型热点”。
2. 业务延迟：TiDB P99（全局）峰值 `1.35s`；其中 `db-tidb-0` P99 峰值 `2.644s`，而另一实例 `db-tidb-2` 峰值仅 `0.056s`，呈现“单 TiDB 实例显著慢点”。
3. TopSQL（TiDB）：digest `FE60...`（多表 join 的 SELECT）在 `db-tidb-0` 上占用 `52.54%` TiDB CPU（`cpu_ms=16452100`），是 SQL 层 CPU 的主导贡献者。
4. 组件健康：`tidb` 组件重启计数显示 `db-tidb-0`/`db-tidb-2` 各有 `tidb restart_count=1`，且 component_count 中 `tidb first=1 last=2 changes=3`，说明窗口内 TiDB 实例数/可用性存在波动，容易导致流量集中与放大热点。
5. TiKV 侧热点补充：Hotspot 结论指出 `db-tikv-1` 上 digest `57429589...`（`delete from hubspot.pending_events ...`）在该实例 `cpu_pct=61.8%`，属于明确的“单 digest 驱动的 TiKV 热点”信号；同时 TiKV gRPC P99 峰值约 `0.288s`（`db-tikv-1`）。

Causality: TiDB 实例数/进程重启波动 → 负载更集中到 `db-tidb-0` → `db-tidb-0` 被少数高 CPU digests（尤其 `FE60...`）压到 CPU 97% → TiDB 处理能力不足、排队变长 → 业务侧在 17:47 左右出现明显高延迟/接近不可用（08:47Z 对齐）。

Ruled Out / Not Relevant: 基础设施 I/O 侧无明显瓶颈（EBS throttle 严重/中等为 0、disk_io_util max=0.00），且 tidb/tikv/pd 日志 ERROR/WARN 计数为 0，支持“主要是负载/热点而非底层故障”。

Severity: High（用户可感知接近不可用；但证据更像容量/热点导致的性能雪崩，而非存储/网络大面积故障）。

Recommendations:
1. 立刻止血：对 `db-tidb-0` 的连接/流量做均衡（确认客户端/代理是否将大部分流量打到单实例；重启窗口要避免单实例承压），必要时临时扩容 TiDB 实例数或提升 TiDB 规格以降低 CPU 饱和风险。
2. 针对主导 SQL（digest `FE60...`）：把它当作 P0 优化对象（该 digest 占 TiDB CPU 52%+）；结合其 join/过滤条件做索引与执行计划优化（优先减少大表 join 扫描与回表放大）。
3. 针对 TiKV 热点 delete（digest `57429589...`）：将 `hubspot.pending_events` 清理/删除作业降频、分批（更小批次/更低并发/更均匀的 key 范围），避免在单个 TiKV 实例形成热点；必要时检查该表的主键/索引设计是否导致删除集中在同一 region/key 范围。
4. 复盘重启原因：追查为何 `tidb`/`auditlog` 在窗口内发生重启（哪怕日志里没抓到 ERROR/WARN 计数，也需要查部署事件/重启触发源），因为它会显著放大“单点承压→雪崩”的概率。