# Expected Diagnosis: TCID-12985

## Root Cause

TiDB CPU 饱和是主根因。2026-07-30 14:01 CST 工作负载突增约 10 倍（CPU 0.49→2.67 核），导致 2 个 3-核配额 TiDB 节点（wxc2zi 99%、35bplo 81%）达到 CPU 上限，SQL 层 goroutine 排队。慢查询 `wait_time=1.81s >> process_time=0.03s` 且 TiKV cop 响应仅 1.54ms，瓶颈在 TiDB 层。RCU `available_ru=0` 是高工作负载结果而非原因（`request_p90=0.5ms`，RCU 限流 overhead 极小）。

## Evidence Chain

1. **TiDB CPU metrics**: wxc2zi 峰值 2.96/3 核（99%）、35bplo 峰值 2.43/3 核（81%）—— 两个 3-核节点 CPU 饱和
2. **Slow query wait/process ratio**: 主热点 SQL（select userstage）`wait_time=1.81s` vs `process_time=0.03s`，exec_count=379,057；TiKV cop 耗时仅 1.54ms —— 瓶颈在 TiDB SQL 层排队
3. **Resource Control request_p90 = 0.5ms**: 所有节点 resource_control request_p90 ≤ 0.0005s —— RCU 限流开销极小，不是延迟主因
4. **Activity Hub events**: 14:36 ScaleInstanceTiDB started（4C→8C），14:52 completed —— 扩容后 CPU 骤降，验证 CPU 饱和为根因
5. **RCU available_ru = 0 全窗口**: default RG available_ru 持续为 0 —— 是 CPU 饱和下大量请求消耗 RU 的结果（不是原因）

## Causality

工作负载突增 10× (14:01 CST) → TiDB 3-核节点 CPU 饱和 (99%/81%) → SQL goroutine 排队 → wait_time >> process_time → 全集群 P99 延迟 1.5–6.2s → ScaleInstanceTiDB (14:36) 增加 CPU 核数 → 14:52 完成后 CPU 骤降

RCU 旁支：CPU 饱和 → SQL 处理慢 → 每条 SQL 消耗更多 RU → available_ru 耗尽（结果，非原因；request_p90 < 1ms 证明 RCU 限流本身无显著延迟）

## Severity

High（生产集群，延迟影响所有用户请求约 52 分钟）

## Recommendations

1. **确认 RCU 不是根因**：解释 `request_p90=0.5ms` 说明 RCU 限流 overhead 极小；告知用户提高 RCU 上限不解决 CPU 饱和问题
2. **扩容 TiDB 节点**：已通过 ScaleInstanceTiDB (4C→8C) 验证有效
3. **调查 14:01 工作负载突增原因**：应用侧是否有批量任务/重试风暴/新版本上线
4. **添加 CPU 利用率自动扩展告警**：TiDB CPU > 70% 持续 5min 触发 autoscale
5. **ANALYZE TABLE tsx.UserStage**：修复 estRows=21 vs actRows=117（5.5×偏差）

## Scoring Rubric

> Checklist for regression testing. The Agent must satisfy these to pass.

- [ ] 识别 TiDB CPU 饱和为主根因（wxc2zi 99%、35bplo 81%）
- [ ] 提供慢查询 wait_time >> process_time 比值作为 TiDB 层排队证据
- [ ] 验证 TiKV 侧 cop 响应时间正常（1-2ms 量级），排除 TiKV 为瓶颈
- [ ] 读取 resource_control request_p90 指标，明确 RCU 限流 overhead < 5ms，说明 RCU 耗尽不是延迟主因
- [ ] 从 Activity Hub 事件确认 ScaleInstanceTiDB 操作及时间点，验证扩容解决了 CPU 饱和
- [ ] 建议调查 14:01 工作负载突增的应用侧原因