- 加载诊断与数据访问能力，并确认该集群的部署类型/指标路由范围  
- 将给定 UTC 时间窗转换为可用于日志/事件检索的时间戳范围  
- 在该时间窗内检索包含 `recoverable goroutine panic`/`panic` 关键字的组件日志，定位具体 panic 栈与组件实例  
- 结合告警规则与日志证据判断是否真实告警、panic 类型/严重性、影响面，并给出处理建议与后续验证动作- 确认集群类型与该时间窗的组件健康/重启情况，避免把“可恢复 panic”误判为进程崩溃
- 在时间窗内检索 TiDB/TiKV/PD/TiFlash 日志中的 `recoverable goroutine panic`/`panic`，定位具体组件与实例
- 结合日志里的 `r=`/错误码与同窗性能证据，判断 panic 触发原因、是否真实告警、影响面与严重性
- 给出可操作的处置建议（优先从触发条件：语句超时/查询形态入手）

结论（告警是否真实）
- 告警“有真实日志触发”，但属于 TiDB 代码路径里的“可恢复 panic”（WithRecovery 捕获），不是 Go 运行时崩溃/进程退出；更接近“用 panic 作为中断/保护机制 + 被恢复后记录”的场景，属于偏噪声型告警。

对应 panic 日志（关键片段）
- 2026-04-19 21:50:00.323Z，TiDB：`misc.go:95` 记录 `"panic in the recoverable goroutine"`，`r="[executor:3024] Query execution was interrupted, maximum statement execution time exceeded"`，实例：`db-2006015162468798464-fc67a2f2-tidb-5`
- 同一时间点附近，TiDB：`agg_util.go:93` 记录 `"parallel hash aggregation panicked"`，并指向 `aggregate.recoveryHashAgg`，同样携带 `error="[executor:3024]... maximum statement execution time exceeded"`，实例包含：
  - `db-2006015162468798464-fc67a2f2-tidb-5`
  - `db-2006015162468798464-fc67a2f2-tidb-2`
- 2026-04-19 21:52:16.746Z/21:52:16.747Z，TiDB：同样的 `"parallel hash aggregation panicked"` + `executor:3024`，实例：`db-2006015162468798464-fc67a2f2-tidb-0`

panic 类型与严重性判断
- 类型：TiDB 内部 `util.WithRecovery` 捕获的“recoverable goroutine panic”，发生在并行 HashAgg 的恢复逻辑附近（`recoveryHashAgg`），触发原因与 `maximum statement execution time exceeded` 强相关
- 严重性：低到中
  - 低：因为没有证据显示 TiDB 进程崩溃/重启（该时间窗内组件数量稳定：TiDB 24、TiKV 54、PD 3）
  - 中：如果此类事件频繁出现，会导致大量查询被强制中断并影响业务成功率；但本窗内命中次数很少（日志模式总行数仅 11 行级别）

关键证据链（从“告警”到“影响”）
1) 日志直接证据：出现 `panic in the recoverable goroutine`，并明确写出 `r=[executor:3024] ... maximum statement execution time exceeded`
2) 同窗组件健康：无 TiDB/TiKV/PD 组件数量变化迹象，支持“未崩溃、未大面积重启”
3) 同窗工作负载/性能侧证：存在明显的重查询迹象（TopSQL/decoded_plan 中可见 `process_time` 很高、处理 keys 数量很大），与“语句超过最大执行时间而被中断”一致

影响判断
- 主要影响是：部分查询在达到最大执行时间阈值后被中断，客户端可能看到 `executor:3024` 类错误；不支持“集群不稳定/进程崩溃/数据损坏”的结论
- 影响面偏局部：日志集中在特定 TiDB nodegroup（`db-2006015162468798464-fc67a2f2`）的少数实例上

处理建议（按优先级）
1) 先把它当“语句超时导致的可恢复 panic”处理：排查业务侧是否设置了较激进的 `max_execution_time`/语句超时；确认是否在该时间点有并行聚合类大查询被频繁 kill
2) 针对重查询做优化/降载：优先从该时间窗内高消耗 digest 入手（decoded plan 显示处理 keys 很大、process_time 很长），减少单次扫描/聚合代价，避免触发超时中断
3) 若告警频繁且确认为“预期中断”噪声：再考虑从告警侧做降噪（例如对明确的 `executor:3024` 场景单独分级/抑制），避免把“可恢复中断”当成“panic 事故”升级响应