# Expected Diagnosis: GH-501

## Root Cause

TiKV read hotspot driven by two high-frequency large-scan SQL workloads: digest F2C6... (three-table LEFT JOIN on dh_account_ext_parentinfo) and digest 470AA5... (IndexLookUp on dh_active_receive_logs). These drive `unified_read` thread saturation on db-tikv-0, db-tikv-23, db-tikv-26, causing gRPC P99 latency to spike (db-tikv-2: 3.7s, 7.4x peers).

## Evidence Chain

1. TiKV CPU metrics: db-tikv-23 = 79%, db-tikv-0 = 77%, db-tikv-26 = 71% (32-core nodes); dominant thread: `unified_read`
2. TopSQL per-instance: F2C6... digest = 39% CPU on db-tikv-0 and 38% on db-tikv-26; 470AA5... = 23% on db-tikv-23
3. TiKV gRPC P99: db-tikv-2 = 3.701s (7.4x peer avg), db-tikv-14 = 1.255s (2.5x) — read hotspot induced queuing
4. Activity Hub: `ModifyClusterVolume` completed at 16:05 UTC+8 (1.5h before 17:30 incident onset) — unrelated
5. component_health tidb:12→1 / tikv:27→11 is Prometheus window truncation artifact, NOT real node down

## Causality

High-frequency large-scan SQL → TiKV `unified_read` CPU saturation (77-79%) → gRPC queue buildup → P99 latency spike → cluster-wide read latency degradation at 17:30 UTC+8

## Severity

High

## Recommendations

1. Add index or rewrite digest F2C6... (dh_account_ext_parentinfo three-table LEFT JOIN) to avoid full table scan
2. Optimize digest 470AA5... (dh_active_receive_logs IndexLookUp) — check if index covers the query pattern
3. Monitor `unified_read` CPU as early warning indicator for read hotspot recurrence

## Scoring Rubric

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

- [ ] Identifies TiKV `unified_read` CPU saturation as the primary bottleneck
- [ ] Names at least one hot TiKV instance (db-tikv-0, db-tikv-23, or db-tikv-26)
- [ ] Identifies digest F2C6... or the dh_account_ext_parentinfo query as a main contributor
- [ ] Reports gRPC P99 anomaly (any instance >2x peer average)
- [ ] Correctly identifies ModifyClusterVolume as IOPS adjustment (not topology change) and rules it out as cause of 17:30 incident
- [ ] Does NOT treat component_health count drop (tidb:12→1, tikv:27→11) as real node failure
- [ ] Converts epoch timestamps via script (not mental math)