# Expected Diagnosis: O11Y-2622673

## Root Cause

`reviews` 表聚合评分 SQL（digest `bc6171e8f6cde9f502c94de777fcd4fb7e78df4b671b1715f544f1a824d43a81`）存在 8 个 plan_digest 并存，其中 `2d7c47cf`（avg 9.1s，max 106s）和 `1dd1366f`（avg 6.9s）的 total_keys 远大于 process_keys，说明这两个执行计划的索引选择低效（大量 skipped keys），导致 expensive query 数量持续超过 500/10min 阈值。告警触发时间 2026-07-24 07:22:31 UTC，集群 ID 10123293495242577103。

## Evidence Chain

1. **SlowQuery logs（按 plan_digest 拆解）**: 4 天内 `bc6171...` 共 8 个 plan_digest 并存；`2d7c47cf` 的 avg_process_keys=929,996，total_keys/exec=1,393,870（skip 率 33%），avg 9.1s；`1dd1366f` avg 6.9s，total_keys > process_keys
2. **SlowQuery logs（告警时间窗口 07:12~07:38 UTC）**: `bc6171...` 26 分钟内执行 1,787 次，total_process_keys 15.1 亿；`auth` binlog 全表扫 avg 28.5s，max 264s，9,192 次执行
3. **Plan 稳定性验证**: `bc6171...` 的 8 个 plan_digest 均在 7/21 00:00~09:27 UTC 首次出现，告警前后无 plan 切换，问题为持续性低效 plan 并存而非突发 plan 变化

## Causality

多 plan 并存（8 个 plan_digest）+ 低效索引选择（`2d7c47cf`/`1dd1366f` skip 率高）→ 高频慢查询（bc6171 avg 2.6s，最慢 plan avg 9.1s）→ expensive query count > 500/10min → 告警持续触发且未恢复。

## Severity

Medium（告警持续未恢复，但查询仍在执行，属查询优化问题而非服务中断）

## Recommendations

1. **优化 `bc6171...` SQL 执行计划**: 拉取 `2d7c47cf` 和 `1dd1366f` 的 decoded_plan，确认低效索引；考虑 `ANALYZE TABLE reviews` 更新统计信息以修正 plan 选择，或添加 SQL hint 强制使用高效 plan（参考 `80f182ac`，avg 0.65s）
2. **优化 `auth` binlog 全表扫**: `2aaff87040e4...` avg 28.5s，max 264s，需优化 binlog 处理查询以避免全表扫描
3. **设置查询超时保护**: 对长跑 expensive query 设置合理的 `MAX_EXECUTION_TIME` hint 或 resource group 限制，防止单查询消耗过多资源

## Scoring Rubric

> Checklist for regression testing. The Agent must satisfy these to pass.

- [ ] 识别 `bc6171e8f6cde9f502c94de777fcd4fb7e78df4b671b1715f544f1a824d43a81` 为扫描量最高的 digest，关联 `reviews` 表
- [ ] 查询 `bc6171...` 的 plan_digest 分布，发现多执行计划并存（≥4 个）
- [ ] 识别 `2d7c47cf` 或 `1dd1366f` 为低效 plan（avg query_time > 5s 或 total_keys >> process_keys）
- [ ] 确认告警时间段内该 SQL 持续高频执行（exec_count > 1000 in 26 min 窗口）
- [ ] 给出执行计划优化方向（ANALYZE TABLE 或 SQL hint 或索引优化）
- [ ] 在查询慢查询时正确使用 epoch 时间范围（1784877xxx 量级，而非 1753xxx）