# Postmortem: TCID-12985

> Workspace: `ws-1785896640589-783164024`
> Date: 2026-08-07
> Reviewer: evolver-bot

## Issue Summary

| Field | Value |
|-------|-------|
| Issue ID | TCID-12985 |
| Alert Type | TiDB 延迟升高 / Serverless Premium 集群 |
| Cluster ID | 10393794543881917049 |
| Cluster Type | premium |
| TiDB Version | 不明 |
| Time Window | 2026-07-30 13:00–16:00 CST（event: 14:01 CST 骤升） |

**Issue Description**: Premium 集群在 2026-07-30 14:01 CST 发生 P99 延迟骤升（0.024s → 1.13s → 峰值 5.65s）。用户反馈："RU耗尽不是原因，客户提高了RCU，但是因为等待RU用不上去。能不能从slow query中看看latency最长的部分来自哪里。"

## Actual Root Cause

> Human-confirmed root cause from user feedback and data analysis.

**TiDB CPU 饱和是主因**（非 RCU 耗尽）。两个 3-核配额 TiDB 节点（wxc2zi 99%、35bplo 81%）承载了全部流量，SQL 层 goroutine 排队。慢查询显示 `wait_time=1.81s` vs `process_time=0.03s`——等待时间远超处理时间，为 TiDB goroutine 排队特征。RCU `available_ru=0` 是高工作负载的**结果**（大量请求消耗了全部 RU token），而非 latency 的主要来源（`request_p90 = 0.5ms`，RCU 限流开销极小）。根本触发点是 14:01 CST 工作负载突增约 10 倍（CPU 0.49→2.67 核，RCU 1,700→13,509 RU/s），根因修复需要扩容 TiDB 节点 / 调查应用侧流量飙升原因。

## Agent Diagnosis Summary

> What the Agent concluded (final answer from unguided first attempt).

Agent 执行了 36 次 tool call（35 completed / 1 failed），无人工干预。

1. **collect_evidence 采集**：在 Premium 集群上正确采集了 metrics、slow queries、decoded_plan、activity hub events、logs
2. **CPU 饱和识别**：正确识别 wxc2zi（99%）和 35bplo（81%）为热点节点
3. **慢查询分析**：从 0026_A3b_row.json 读取了 `wait_time=1.81s vs process_time=0.03s`，并引用 TiKV cop_task 耗时仅 1.54ms
4. **RCU 分析**：将 `available_ru=0` 定性为"叠加机制"，认为 RCU 限流对每次请求增加了额外等待
5. **扩容确认**：从 Activity Hub 正确识别了 14:36 ScaleInstanceTiDB 操作及 14:52 完成恢复

**诊断准确性**：主根因（CPU 饱和）正确，但 **RCU 叠加归因存在误导**。Agent 未验证 `request_p90=0.5ms` 这一关键反证——该数据已在 evidence_summary 中，证明 RCU 限流实际开销极小，不是 latency 主要来源。Agent 还未提供用户要求的 **wait_time 分解分析**（慢查询 wait_time 中各子项：network、cop、lock wait 占比）。

## Scores

| Dimension | Score (1-5) | Notes |
|-----------|-------------|-------|
| Root Cause Accuracy | 4 | CPU 饱和根因正确，但将 RCU 定性为"叠加机制"有误导性，未使用 request_p90=0.5ms 反证 |
| Evidence Completeness | 4 | 覆盖了 metrics/slow queries/decoded_plan/events；缺少 slow query wait_time 子项分解 |
| Causal Chain | 4 | 因果链完整，但 RCU 分支的因果逻辑不严谨（将结果当原因） |
| Actionability | 4 | 建议具体，但缺少"提高 RCU 后仍无改善"的解释，用户可能仍困惑 |
| Efficiency | 4 | 36 tool call，无人工干预，1 次 failed（write_analyst_report.py，已知 ISS-0113）。效率良好 |
| **Overall** | **4.0** | |

## Human Guidance Log

> No human interventions in this workspace. User feedback was submitted via GitHub issue post-diagnosis.

## Skill Deficiencies

### SD-1: RCU 限流归因缺少 request_p90 反证验证

- **Type**: REASONING
- **Skill**: `tidb-perf-diagnosis`
- **Current behavior**: Agent 看到 `available_ru=0` 就将 RCU 定性为"叠加机制"影响延迟，但未核验 `request_p90` 以量化 RCU 限流的实际 overhead
- **Expected behavior**: 当 available_ru=0 时，应读取 `request_p90` 指标：若 request_p90 < 5ms，RCU 限流不是 latency 主因；若 request_p90 > 100ms，才认为 RCU 限流显著影响延迟
- **Suggested fix**: 在 SKILL.md 增加 Resource Control 分析规则：available_ru=0 需配合 request_p90 量化限流 overhead，仅在 request_p90 高（>50ms）时才归因为延迟主因
- **Priority**: P2-medium
- **Issue**: ISS-0121

### SD-2: 慢查询 wait_time 分解分析缺失

- **Type**: KNOWLEDGE
- **Skill**: `tidb-perf-diagnosis`
- **Current behavior**: Agent 展示了 `wait_time=1.81s vs process_time=0.03s` 并判断为"goroutine 排队"，但未提供 wait_time 的子项分解
- **Expected behavior**: 当 wait_time >> process_time 时，应进一步分解 wait_time（connection get time、lock wait、coprocessor queue wait、network to TiKV），帮助用户理解具体等待来源
- **Suggested fix**: 在 collect_evidence 的 slow query 采集中，增加对 TiDB slow log 中 `Connection_wait_time`、`lock_time`、`Preproc_time`、`Plan_wait_time` 字段的提取；在 SKILL.md 中增加 wait_time 分解分析指引
- **Priority**: P2-medium
- **Issue**: ISS-0122

## Key Queries

### Resource Control 限流 overhead 量化

```sql
-- 验证 RCU 限流对每个请求的实际延迟 overhead
-- request_p90 < 5ms = RCU 限流不是 latency 主因
SELECT instance, resource_group, peak, mean
FROM resource_control_request_p90;
-- TCID-12985: 所有节点 p90 = 0.0005s (0.5ms) → RCU 限流 overhead 可忽略
```

### TiDB 慢查询 wait_time 组件分解

```sql
SELECT digest, query_time, process_time, wait_time,
       Connection_wait_time, lock_time, Plan_wait_time, Preproc_time
FROM clinic_data_proxy.slow_query_logs
WHERE date = '20260730' AND time >= 1785387600
ORDER BY query_time DESC LIMIT 20;
```

## Lessons Learned

- `available_ru=0` + 高 RCU 消耗不等于"RCU 限流是延迟主因"——必须结合 `request_p90` 量化限流的实际 overhead
- 工作负载突增场景中，RCU 耗尽往往是 CPU 饱和的**结果**而非**原因**：CPU 饱和 → SQL 慢 → 每条 SQL 消耗更多 RU → available_ru 耗尽
- 慢查询 `wait_time >> process_time` 之后还需一步分解 wait_time 子项，才能完整回答用户"latency 最长的部分来自哪里"