- 先拉取集群元信息（部署形态/是否 Premium、parent_id/keyspace 等），确定指标路由范围  
- 按知识库规则完成指标路由校验与“常见误判”约束检查  
- 在给定 1 小时窗口内采集证据（TopSQL/慢查询/等待事件/关键组件指标/日志与事件）并定位 P999 飙升对应的瓶颈点  
- 基于证据链给出最可能根因、影响面判断与可执行的处置/验证建议Root Cause: 高并发更新同一类“按 merchant_id 定点写单行累计字段”的热点写入，触发严重行锁竞争/锁等待（而非 CPU/IO 瓶颈），导致 TiDB 尾延迟在窗口内显著拉长并出现业务超时。

Key Evidence:
1. 慢查询主导语句为定点更新且耗时极高：`update t_merchant_online ... where merchant_id=?` 在该窗口内 `exec_count=43388`，`avg_time=7.81s`，`max_time=18.17s`；`update t_merchant_ol_pay_type ... where merchant_id=? and pay_type=?` `exec_count=37286`，`avg_time=11.92s`，`max_time=21.87s`。
2. 对上述 digest 抽取到的执行形态为单行点查更新并带锁：`Point_Get ... op=handle:?, lock`（典型“同一行/同一 key 高并发写”时的锁竞争放大器）。
3. 同时段 TiDB 侧错误/告警量在后半段显著放大（分钟级计数最高到数千级），与业务“超时明显”现象一致；而基础设施与热点实例门禁均为 CLEAR/未检出（排除 EBS/磁盘与单机 CPU 热点为主因）。
4. TiDB CPU 与 GC 指标正常区间：TiDB CPU 利用率约 32–33%；GC 频率/暂停/耗时均正常，说明不是“TiDB 计算/GC 饱和”导致的长尾。

Causality: 热点 merchant_id（及 merchant_id+pay_type）上的高并发定点更新 → 行锁等待/冲突与重试放大，单语句耗时达 10–20s 级 → 请求排队与超时 → TiDB P99 在窗口内峰值约 18–19s、业务侧观测到更高分位（P999）接近 30s。

Ruled Out / Not Relevant: Infra gate 为 CLEAR、无磁盘/EBS 证据；实例级 hotspot 未检出；TiDB CPU/GC 正常，因而不支持“资源不足/GC 抖动/单实例打满”为主因。

Severity: High（写路径长尾达 10–20s 级，且 exec_count 很高，易造成级联超时与积压）。

Recommendations:
1. 立刻止血（应用侧）：对同一 `merchant_id`（以及 `merchant_id+pay_type`）的更新做串行化/合并（本地聚合后批量刷回、按 key 分区队列、限流），并为写入重试增加指数退避与抖动，避免锁冲突风暴。
2. 结构性改造（推荐）：将“单行累加计数器/金额”改为可并行写的分片计数（例如按 `merchant_id` + `shard` 多行累加，异步汇总），或改为事件流/异步记账，避免所有写集中到同一行。
3. 数据库侧核验与调参方向：确认事务模型与锁行为（是否悲观事务、锁等待超时设置、是否存在大量冲突重试）；若短期无法改造，优先通过降低并发冲突而不是单纯调大超时（调大只会把超时变成更长的尾延迟）。
4. 进一步证据补强（用于精确定位“哪些 key 最热”）：在业务侧按 `merchant_id`/`pay_type` 打点统计并输出冲突/重试/耗时分布，找到最热 key 集合，作为限流/分片策略的直接输入。