- 加载 Premium 集群的分层/指标路由规则，避免拿错作用域（尤其是 parent_id 资源池范围）。
- 固化时间窗（UTC）并作为后续所有证据采集的唯一边界。
- 采集该窗内 P999 SQL Duration/尾延迟对应的 TopSQL、TiDB CPU/GC、KV 延迟/热点/排队等关键证据。
- 基于证据链给出最可能根因、影响判断与处理建议。**最可能根因**
高频 `DELETE ... WHERE id BETWEEN ... AND created_time >= ... AND created_time < ...` 走了不合适的访问路径（`indexes_used: \\N`），在 TiKV 侧产生了大范围扫描/过滤与锁相关开销，叠加业务整体 QPS 很高，最终把多个 TiDB 实例 CPU 推到接近饱和，触发 P999/P9999 尾延迟显著上升。

**关键证据链**
1. 热点/饱和：同一时间窗内 5 个 TiDB 实例出现 CPU saturation（>80% quota），最高 `27.0/31 cores (87%)`（见 Key Findings + `TIDB CPU`）。
2. 尾延迟对应的慢 SQL：慢查询 Top1 digest 为上述 `DELETE`，`exec_count=4978`，`avg_time=1.26s`，`max_time=19.39s`（见 `slow_queries`）。
3. 访问路径/扫描放大：该 digest 的 `decoded_plan` 显示 `TableRangeScan` + `Selection(created_time...)`，`indexes_used: \\N`；单次 `process_keys=8829715`、`total_keys=5996`，明显“扫描/过滤放大”（见 `decoded_plan`）。
4. 放大发生在高负载背景下：同窗内语句速率很高（`Select mean ~50867/s`，`Update mean ~13897/s`，`Commit mean ~6546/s`），CPU 更容易被这类放大型查询拖入饱和，尾延迟随之恶化（见 `workload`）。
5. 排除主要外因：Infra gate 为 CLEAR（EBS/disk IO 无明显异常）；资源管控排队不明显（`request_p90` 量级毫秒、未见 throttling 形态）（见 `Key Findings` + `resource_control`）。

**因果链**
不合适的索引/访问路径 → `DELETE` 在 TiKV 侧大量扫描/过滤（process_keys 放大）+ 锁/写放大 → 多个 TiDB 实例 CPU 进入 80%+ 饱和区 → 查询排队/执行时间长尾增大 → P999 SQL Duration/尾延迟异常。

**影响判断**
- 严重性：High（已出现多 TiDB 实例 CPU 饱和，尾延迟对业务可感知；并且该慢 SQL 高并发/高频出现，具备持续放大风险）。
- 影响面：不仅是单条 SQL 变慢，而是对同一组 TiDB 实例上的整体请求产生“排队型”尾延迟外溢。

**处理建议**
1. 立刻缓解：对该 `DELETE` 做限速/降并发/分批（更小 `id` 范围、更短时间窗），避免单次扫描与锁时间过长；必要时临时下线该清理任务或改为异步低峰执行。
2. 根治（优先）：为该过滤条件补齐可用索引/访问路径（围绕 `created_time` 的范围条件与 `id` 范围组合设计复合索引，或调整 SQL 使其能稳定命中高选择性索引）；目标是把 `process_keys` 量级显著降下来。
3. 校验与回归：上线前后对比该 digest 的 `process_keys/total_keys`、`avg/max time` 与 TiDB CPU saturation 是否消失；若仍有尾延迟，再进一步看是否存在其他高频放大 SQL（本次证据里 TopSQL 缺失，建议补齐 TopSQL/statement summary 以做 CPU 归因闭环）。
4. 旁路观察：TiDB GC pause P99 有 `~0.117s` 的 warning 级别波动，但当前更像“高负载下的伴随现象”而非主因；若后续仍有 TiDB CPU 异常，可追加 continuous profiling 来确认 CPU 热点栈。