Now let me read the KB files (Step A and Step B) before collecting evidence.Now let me get cluster metadata to determine the tier, then collect evidence.**KB Step A 完成：** 这是 **Dedicated** 集群，`cluster_type_v2 = "dedicated"`，所有组件（TiDB、TiKV、PD、TiFlash、node）均使用 `cluster_id` 路由指标。无需 `parent_id`。

**KB Step B 完成：** 已加载 `incorrect-conclusions.json`，关键规则：
- `ic-001`: TopSQL/SlowQuery 中 ANALYZE 出现不代表是根因，需先排除应用 SQL；
- `ic-002`: estRows/actRows 大幅偏差不能直接得出 "统计信息过旧" 为 P0，需先确认是否缺少索引。

现在收集证据：证据收集完成，现在进行分析。

**Node C/D 分析：**

**TiDB 层：** 4 个默认 nodegroup 的 TiDB 实例（db-tidb-0/1/2/5）CPU 均达到 86-90%（55-58 cores / 64 quota），触发 critical CPU saturation；另一 nodegroup（ac-2006015162468798464，14个实例）CPU 仅 28-34%，正常。

**TopSQL TiDB 层：** digest `18576E` (`select * from dh_audit_record where user_id=? and site_code=? and status in (...) and charge_time < ? order by charge_time asc, id asc`) 在 db-tidb-0/1/2/5 四个热实例上分别占 2.89%、2.96%、3.47%、3.67% CPU，合计约 **13%** 的 TiDB CPU。TiDB 空 digest 在 ac 节点组消耗 2.25~2.52%，属于正常。

**TiKV 热点：** db-tikv-29、db-tikv-37、db-tikv-10 出现热点。热实例 TopSQL-TiKV `cpu_pct` 显著：

- `7DD99B`（`select id from dh_account_details where username=? and opt_type in (...) and auditorderid is ? and demands_bet > ? and site_code in (?)`）: db-tikv-37: **11.39%**，db-tikv-10: **9.27%**，db-tikv-29: **5.02%**
- `470AA5`（`select dh_active_receive_logs...`）: db-tikv-37: **11.05%**，db-tikv-10: **9.01%**，db-tikv-29: **3.67%**
- `43D2B9`（`select ? as create_ymd, t2.register_currency, count(t2.useridx) as login_persons from dh_user_action_logs...`）: db-tikv-10: **17.14%**，db-tikv-37: **10.17%**，db-tikv-29: **8.01%**
- `9505CA`（`commit`）: db-tikv-29: **10.37%**，db-tikv-37: **8.48%**，db-tikv-10: **10.26%**
- `F2D5E7`（`select version, table_id, modify_count, count, snapshot from mysql.stats_meta where version > ?`）: db-tikv-29: **4.93%**，db-tikv-10: **2.03%**

TiKV thread CPU：热实例上 `unified_read` 线程最热（db-tikv-29: 8.36，db-tikv-37: 6.29，db-tikv-10: 5.87），其次是 `grpc`（约 5.0），证实是读热点驱动。

**ic-001/ic-002 pitfall 检查：** `F2D5E7`（stats_meta 读取）属于 TiDB 统计信息后台轮询，在 db-tikv-29 占 4.93%，不是主导。不存在 ANALYZE 作为主因的情况。主因是应用 SQL 读热点，符合 ic-001/ic-002 规则。

**查询根因条件校验（Node D 决策）：**

1. 领先原因是查询驱动 ✅（`unified_read` 线程热，多条应用 SELECT 占据 TiKV hot instance 前列）
2. 同一 TiKV 热实例 CPU 急升 ✅（db-tikv-29/37/10 均高于 peer avg，grpc_p99 达 peer avg 的 5.3x）
3. 查询主导该热实例 CPU：`43D2B9` 在 db-tikv-10 达 17.14%，`7DD99B` + `470AA5` 在 db-tikv-37 合计 22.4% ✅
4. 时间对齐 ✅（整个窗口持续）

→ **这是查询根因案例**，需进一步分析 SQL 和执行计划。

**Node E 交叉验证：**

1. TiDB CPU 饱和（86-90%）但无对应大单 SQL 超过 ~14%；TiDB 侧高 CPU 是大量并发请求的叠加效应（Select QPS 峰值 77,831/s，commit/begin 各 ~15,000/s），不是单条 SQL 的执行低效。
2. TiKV 热点是读密集型：`unified_read` > `grpc` >> `raftstore`，三个 SQL 族（dh_user_action_logs、dh_active_receive_logs、dh_account_details）在热实例贡献 **>30% CPU**。
3. GC（Go GC）正常：gc_duration_rate 峰值 0.003 s/s，gc_pause_p99 峰值 117ms（warning 级），不足以解释 86-90% CPU 饱和。
4. 基础设施正常：EBS throttle 极低，disk IO util = 0，组件数量零变化，日志 0 错误。
5. 无 decoded_plan——需要额外分析三条热 SQL 的执行计划；但 TiKV thread 类型（`unified_read` 主导）已确认是全表/大范围扫描/点查模式，且多个热点 SQL 均缺乏通过索引收窄结果集的条件（多列范围+多 site_code）。

---

## 诊断结论

---

**Root Cause**

在事件窗口 2026-04-07T22:00Z – 2026-04-08T01:30Z，**默认 nodegroup 的 4 个 TiDB 实例（db-tidb-0/1/2/5）因承接高并发应用查询（Select QPS 峰值 ~7.8 万/s）而 CPU 全部饱和（86–90%）；根本驱动来自 TiKV 侧三类高频读 SQL 在 db-tikv-29、db-tikv-37、db-tikv-10 三个热节点上形成 `unified_read` 线程热点，导致 gRPC P99 延迟最高 102ms（peer avg 5.3x），反压至 TiDB 执行层引发全集群 CPU 高企。**

---

**Key Evidence**

1. **TiDB CPU 饱和**：db-tidb-0/1/2/5 峰值 55.2–57.6 cores / 64 quota，利用率 86–90%（critical），同节点组 4 实例全部触发；ac-nodegroup（14 实例）仅 28–34%，对比显著。
2. **TiKV gRPC 热点**：db-tikv-29 gRPC P99 = 102ms（peer avg 19ms，**5.3x**）；db-tikv-22/6/50 均达 2.2–2.3x；热实例 `unified_read` 线程峰值 8.36 cores（db-tikv-29），证实大量读扫描集中在少数节点。
3. **TopSQL TiKV 热实例 CPU 归因**（三条主力 SQL）：
   - `43D2B9`（`dh_user_action_logs` 聚合统计）：db-tikv-10 **17.14%**，db-tikv-37 **10.17%**，db-tikv-29 **8.01%**
   - `7DD99B`（`dh_account_details` 索引查询）：db-tikv-37 **11.39%**，db-tikv-10 **9.27%**，db-tikv-29 **5.02%**
   - `470AA5`（`dh_active_receive_logs` 宽表 SELECT）：db-tikv-37 **11.05%**，db-tikv-10 **9.01%**，db-tikv-29 **3.67%**
   - `commit`（`9505CA`）：各热实例 8–10%，反映高写事务量叠加
4. **慢查询佐证**：`dh_audit_record`（avg 1.32s，max 2.82s，728次）、`dh_account_basic` 宽表 JOIN（avg 1.1s，max 2.26s，430–394次）、`dh_promote_myteam_direct` CTE（avg 1.2–2.08s）等多条业务 SQL 均超阈，与 TiDB P99 延迟升高（db-tidb-2 峰值 250ms）吻合。

---

**Causality**

高并发业务报表/用户查询（`dh_user_action_logs`、`dh_active_receive_logs`、`dh_account_details` 等）→ 读请求集中路由至少数 TiKV 实例（region 热点）→ `unified_read` 线程饱和，gRPC P99 升至 5.3x peer avg → TiDB 等待 TiKV 响应时间拉长，同时高 QPS 叠加大量并发 → 默认 nodegroup TiDB CPU 86–90% 饱和 → TiDB P99 延迟上升（最高 250ms），用户侧慢查询增多。

---

**Ruled Out / Not Relevant**

EBS 无 throttle、disk IO = 0、组件数量零变化、日志零错误；Go GC 正常（rate < 0.003 s/s）；`stats_meta` 轮询仅占热实例 TiKV CPU 4.93%，不是主因（ic-001/ic-002 规则已核实）。

---

**Severity**：**High**

TiDB 默认 nodegroup 4 节点全部 critical CPU，TiKV 出现多节点热点并伴有明显 gRPC 延迟抖动；事件持续 3.5 小时；用户侧慢查询 avg 1–2s，max 达 8s。

---

**Recommendations**

**P0 — 立即缓解热点**

1. **执行计划 / 索引核查（三条主力热 SQL）**
   - `dh_user_action_logs`（`43D2B9`）：`SELECT site_code, useridx FROM dh_user_action_logs WHERE name=? AND ...`，需确认 `(name, site_code, useridx)` 或 `(name, ...)` 覆盖索引是否存在；`unified_read` 热说明走的是范围扫描而非 index point-get。
   - `dh_account_details`（`7DD99B`）：`WHERE username=? AND opt_type IN (...) AND auditorderid IS ? AND demands_bet > ? AND site_code IN (?)`，多列复合谓词，需检查是否有 `(username, site_code, opt_type)` 复合索引；`demands_bet > ?` 范围条件若排在前缀会导致大范围扫描。
   - `dh_active_receive_logs`（`470AA5`）：多 site_code 宽表 SELECT，检查是否存在 `(log_category, log_status, site_code, period_time)` 覆盖索引。
   - **操作**：`EXPLAIN` + `EXPLAIN ANALYZE` 查看实际执行计划，若存在 `IndexFullScan` 或 `TableFullScan`，优先 `CREATE INDEX`，再考虑 SQL Binding 固化计划。

2. **ANALYZE 验证**（配合索引创建后）
   - 若上述 SQL 执行计划正确但 estRows 与 actRows 偏差大（>10x），再执行 `ANALYZE TABLE dh_user_action_logs, dh_account_details, dh_active_receive_logs`，并检查 `SHOW STATS_HEALTHY` 确认健康度 < 80% 的表。

**P1 — 热点分散**

3. **TiKV Region 热点打散**：考虑对 `dh_user_action_logs`、`dh_active_receive_logs` 等高频读表使用 `SHARD_ROW_ID_BITS` 或 `PRE_SPLIT_REGIONS`（若是新表），或使用 `pd-ctl` 手动切分热 region，将 db-tikv-29/37/10 的 Region leader 迁移到低负载节点。

4. **连续性能剖析**：对 db-tidb-0/1/2/5 开启 continuous profiling，采集 2–3 次 CPU 火焰图，确认 TiDB 侧 CPU 消耗的具体函数路径（executor 执行、compile/optimize、coprocessor 请求等），以区分是 SQL 编译开销还是执行调度开销。

**P2 — 负载均衡**

5. **检查 ac-nodegroup 路由策略**：ac 节点组（14 实例，CPU 仅 28-34%）有大量空余容量，排查 TiProxy / 连接池路由配置，确认是否可将部分读请求均衡分发到 ac 节点组，避免默认 nodegroup 单侧过载。

6. **慢查询长期治理**：`dh_audit_record`（avg 1.32s，SELECT \*，无分页限制迹象）、`dh_promote_myteam_direct` CTE（avg 1.2–2.1s）等需做业务侧分页改造或查询拆分，避免单次全量扫描。