计划：
- 先确认时间窗的精确时间戳（UTC）并确定需要采集的证据范围
- 拉取集群元信息并按集群类型做指标路由，避免采集范围错误
- 采集该时间窗内的关键指标/日志/事件/慢查询与TopSQL证据，建立证据链后归因并给出处理建议计划：
- 基于该时间窗的证据先做“是否数据库内因”判定（资源/热点/延迟/RCU/组件健康）
- 抽取连接链路相关日志（TiProxy/TiDB）确认是否为接入层故障形态
- 给出最可能根因、证据链、影响判断与处置建议

**Root Cause**：更像是接入层（TiProxy/连接链路）在时间窗末段出现连接转发失败，导致新建连接/请求无法稳定到达 TiDB，从而表现为业务侧“不可用/超时/QPS 下跌”；数据库执行层（TiDB/TiKV）在该窗内未显示出资源瓶颈或热点导致的系统性慢。

**Key Evidence**：
1. **数据库执行侧整体健康**：TiDB P99 查询延迟峰值约 `0.014s`，TiDB CPU 利用率约 `34%~37%`（4 实例），Hotspot 判定为“未检测到”，Infra 判定为“CLEAR”（无 EBS/磁盘 IO 异常）。
2. **连接异常信号集中在 03:23:5xZ 附近**：TiProxy 日志出现大量 “`fails to relay the connection`”（连接无法转发到后端）；同时 TiDB 有 “`read packet timeout, close this connection`（idle≈5m, waitTimeout=300）” 的断连记录。
3. **组件存活/数量无显著波动**：Premium 资源池侧 `tikv/pd/tso/coprocessor-worker/tikv-worker` 数量在窗内首尾一致，未见“实例掉线/重启风暴”这类容量崩溃特征。

**Causality**：TiProxy 连接转发失败/链路不通 → 客户端连接/请求无法进入 TiDB（表现为连接失败/超时）→ 业务侧请求超时、服务不可用、QPS 下跌（由应用侧主动降载/重试失败/连接池耗尽放大）。

**Ruled Out / Not Relevant**：该时间窗内未看到 TiDB/TiKV 资源饱和、磁盘抖动、热点、GC 异常或慢查询/TopSQL 主导导致的全局性能退化（TopSQL 在该窗未返回数据）。

**Severity**：High（接入链路故障会直接造成“不可用/超时”，且对 QPS 影响通常立刻且显著）。

**Recommendations**：
- 立刻聚焦 TiProxy：按更细粒度（例如 03:20–03:25）统计 “fails to relay” 的发生率、对应 backend_addr/错误原因（解析失败、拨号超时、后端不可达、连接数上限等），确认是**TiProxy 自身**还是**到 TiDB 的网络/后端选择**问题。
- 核查应用侧连接模式：是否在故障时段发生连接风暴（连接池失效/频繁建连/探活缺失）；建议启用/加强连接池、合理的 keepalive、降低建连频率与重试风暴。
- 若确认是 TiProxy 层容量/稳定性问题：评估提高 TiProxy 副本/配额、检查 proxy-protocol 配置一致性与 LB/安全组/NACL 变更记录；必要时对该窗前后抓取 TiProxy 指标（连接数、后端连接错误、accept/relay 失败计数）做时间对齐验证。