- 先确认集群类型/路由口径(Premium 的 parent_id 等),避免抓错指标范围 - 把给定 UTC 时间窗转换为证据采集需要的时间戳/参数 - 采集并汇总该时间窗内 TiDB CPU、GC、TopSQL/慢查询、热点与系统事件证据 - 基于证据链给出最可能根因、影响判断与处置建议(含下一步验证项) 根因最可能是:业务读写负载在该时间窗内明显增大/偏斜,触发 TiDB 端 CPU 持续抬升;同时 TiKV 侧出现单点实例 `db-tikv-15` 的 gRPC P99 明显热点(并有一次尖峰到 0.47s),放大了部分请求的执行成本与尾延迟。 **Key Evidence** 1. TiDB CPU(DefaultGroup)整体处于高位:`db-tidb-0/1/2/5` 峰值 39.65–47.73 cores,配额 64 cores 下利用率 62%–75%(warning);而非默认 node group(ac-2006015162468798464)TiDB CPU 峰值 ~14 cores、利用率 ~22%(normal),体现负载分布不均/偏斜。 2. 单个 TiDB 实例存在“持续抬升”形态:`db-tidb-0` 在窗口起止点 CPU 从 5.31 cores 升到 10.31 cores(+5.00 cores),同时 95 分位达 29.87 cores、峰值 45.12 cores,符合“持续升高 + 期间多次高峰”的特征。 3. TiKV 侧存在明确热点:TiKV gRPC P99 `db-tikv-15` 峰值 0.472s,peer 平均 0.031s(15.5x);该实例在时间序列上也出现一次显著尖峰(max=0.472s),与“局部存储侧不均衡/热点”一致。 4. 慢查询样本显示典型高 KV 扫描/回表开销:digest `e0d7...` 的 `process_time=63.98s`,`total_keys=26,651,535`、`process_keys=9,999,776`,并且执行计划为 `IndexLookUp + IndexRangeScan`,属于容易在高 QPS 下显著抬高 TiDB/TiKV 端 CPU 与资源消耗的模式。 **Causality** 负载增长/偏斜(workload:Select 峰值 ~42k/s,均值 ~31.8k/s)→ DefaultGroup TiDB 承压导致 CPU 持续抬升 → 存储侧出现/加剧 TiKV 单点热点(`db-tikv-15` gRPC P99 15.5x)与高开销查询放大 → 业务感知为多个 TiDB 节点 CPU 长时间高于常态、尾延迟波动。 **Ruled Out / Not Relevant** 基础设施侧未见磁盘/IOPS 限流证据:EBS throttle 严重/中度为 0,disk_io_util max=0.00;组件数量/重启无变化;日志中 tidb/tikv/pd 无 ERROR/WARN 计数。TiDB GC 指标整体不高(频率/耗时 rate 正常),但 GC pause P99 有 0.117s 的 warning,暂视为次要放大因子而非主因。 **Severity** High:CPU 持续高位 + 存储侧热点会带来吞吐下降与尾延迟风险(虽 TiDB P99 查询延迟整体不高,但热点信号明确且慢查询样本开销巨大)。 **Recommendations** 1. 优先处置 TiKV 热点:聚焦 `db-tikv-15`,检查该实例 Region leader/peer 分布、热点 region/key range、网络与磁盘时延;必要时做 leader 调度/region balance,缓解单点 gRPC P99 异常。 2. 处置 DefaultGroup 负载偏斜:核查连接入口/负载均衡策略(TiDB 实例间连接与 QPS 是否集中在 `db-tidb-0/1/2/5`),修正路由或会话粘性导致的不均衡。 3. 针对高开销 SQL(digest `e0d7...`):从该 SQL 的筛选条件与索引(已用 `idx_dh_active_acid_status_cate_uptime_site_cb`)出发,评估是否仍存在“范围过宽/回表过多/分页方式不当”的问题;业务侧可先做限流、缩小时间范围、分批/游标分页(避免大范围 TopN+回表在高 QPS 下放大)。 4. 由于本次采集窗口内 TopSQL 为空(`(no topsql data)`),建议补齐 TopSQL/statement summary 能力后,在同类窗口复盘确认“CPU 主要消耗的 SQL digest/内部操作占比”,以把根因从“负载增大/偏斜”进一步收敛到具体 SQL/表/索引或具体热点 key。