Now let me execute KB Steps A and B before collecting evidence.KB Steps A & B done. Now I need to get cluster metadata to determine tier and parent_id before running evidence collection.**KB Step A 完成：** 集群类型为 **Premium**，`parent_id = 2028998946604449792`。  
根据 metric_routing：TiDB 指标用 `cluster_id`，TiKV/PD/TiFlash/node 指标用 `parent_id`。

**KB Step B 约束已加载：** ic-001（避免将 ANALYZE 列为主因）、ic-002（统计信息陈旧 ≠ P0，missing index 才是主因）。

现在用 time-conversion 确认时间戳，然后收集证据。证据收集成功（EBS 查询超时是已知的 503，不影响核心分析）。现在读取证据摘要：证据收集完整，现在进行深度分析。有几个关键发现需要进一步调查。让我查看 TiDB 错误日志详情和 Resource Control 的 RU 使用情况。日志证据非常清晰。现在获取 RU 使用的详细时序数据，以及锁等待相关指标：`chart_data` 在此没有内联数据，数据在 evidence_summary 的预处理摘要中已经提取。现在我有了足够的证据，让我查询 lock wait 相关的补充 Slow Query 数据，特别是关注两条主要 UPDATE 慢查询的完整信息：慢查询日志 API 未返回行级数据（可能该集群此日期的原始行记录存储方式不同），但 evidence_summary 已通过 Clinic 内置 API 给出了聚合的慢查询摘要（exec_count/avg_time/max_time）。现在我已有足够的多维度证据。让我进行最终交叉验证分析：所有关键证据已交叉验证完毕。现在输出最终诊断结论：

---

## 诊断报告：集群 10805087899823024166 尾延迟异常（2026-03-09 04:14–05:14 UTC）

---

### Root Cause

**悲观锁竞争（Pessimistic Lock Contention）导致 P999 延迟飙升**：`t_merchant_online` 和 `t_merchant_ol_pay_type` 两张商户聚合表上，高并发的 UPDATE 语句按 `merchant_id` 更新同一行的累计字段（`amount_by_day`/`total_amount`），造成热点行级写锁争用，大量事务触发 `pessimistic lock retry limit reached`，执行时间被迫拉长至 7–22 秒。

---

### Key Evidence

1. **P99 延迟峰值 18.53s**（tidb-180hpg: 19.3s，tidb-wts9s8: 17.8s），与业务反馈的 P999 接近 30s 量级吻合。
2. **慢查询排名第 1、2 均为同表的 merchant 聚合 UPDATE**：
   - `UPDATE t_merchant_online … WHERE merchant_id=?`：43,388 次执行，avg=7.81s，max=18.17s
   - `UPDATE t_merchant_ol_pay_type … WHERE merchant_id=? AND pay_type=?`：37,286 次执行，avg=11.92s，max=21.87s
   - 两条语句合计约 80,000+ 次慢查询，在 1 小时窗口内持续触发
3. **WARN 日志直接确认锁失败**：两个 TiDB 节点均大量记录 `[WARN] "run statement failed" error="pessimistic lock retry limit reached"` @ session.go:2376，与上述 UPDATE SQL 对应（`sql="update t_merchant_online …"`）。WARN 共 4,479 条，INFO 级 "command dispatched failed" 配对 8,948 条，均在 05:13–05:14 UTC 密集爆发。
4. **Decoded Plan 确认执行路径正确（Point Get + lock）**：`Point_Get_1 est=1 act=1 lock` — 执行计划本身无误（通过主键/唯一键命中单行），延迟完全来自锁等待排队，而非全表扫描或索引缺失。

---

### Causality

高并发支付场景中多路 UPDATE 事务同时争抢 `t_merchant_online`/`t_merchant_ol_pay_type` 的同一 merchant 行热点写锁  
→ TiKV 悲观锁排队积压，大量事务超过默认 retry 上限（`max-retry-limit`）  
→ 事务执行时间拉伸至 7–22s，导致 TiDB 层挂起连接数激增  
→ 业务侧观察到 P999 延迟接近 30s、大量请求超时报错

---

### Ruled Out / Not Relevant

基础设施（EBS、磁盘 I/O）完全正常；TiDB CPU 仅 33% 利用率，GC 健康；无组件重启/OOM；资源管理器 RC 等待时间 0.5ms，无 RU 节流；无 TiKV CPU 热点；ANALYZE 未出现在慢查询中，ic-001/ic-002 规则均不触发。TopSQL 数据缺失，但已通过慢查询+日志双重确认根因，无需 TopSQL。

---

### Severity

**High**（持续 1 小时的 P999 尾延迟 ≥18s，业务超时率显著，两张核心商户表受影响）

---

### Recommendations

#### P0 — 消除热点行竞争（根治）

1. **引入缓冲聚合层**：将高频的 `amount_by_day`/`total_amount` 累加操作改为先写 **流水明细表**（如 `t_merchant_tran_buffer`），由后台任务批量合并到 `t_merchant_online`，解除 OLTP 路径的行级锁竞争。  
   > 这是彻底消除热点的架构方案，推荐在下一次 schema 迭代中实施。

2. **启用 TiDB 悲观锁流水线优化**（短期缓解）：  
   ```sql
   SET GLOBAL tidb_pessimistic_txn_fair_locking = ON;
   ```
   公平锁可减少锁饥饿，但不能解决根本竞争问题。

3. **调大 `pessimistic-auto-commit`/`max-retry-limit`** 以减少立即失败：  
   ```toml
   # tidb.toml
   [pessimistic-txn]
   max-retry-limit = 512  # 默认 256
   ```
   仅作临时缓解，不减少等待总量。

#### P1 — 监控告警补充

4. 为 `tidb_tikvclient_lock_resolver_actions_total{type="cleanup"}` 和 `pessimistic lock retry limit` WARN 日志频率添加告警阈值，实现提前预警。

#### P2 — 业务层并发控制

5. 在应用层对同一 `merchant_id` 的并发更新加入 **应用级队列或 Redis 合并窗口**（如 100ms 内合并同一商户的金额变更），减少到达 TiDB 的锁竞争请求数量。