[YouYangDaShu]

现象

当网关运行数天积累较多请求记录（数万条）后，停留在「报表」页时会出现页面加载极慢、接口超时，甚至导致程序 CPU 满载、系统负载极高、其他接口响应受阻。

成因

经排查，由以下三点叠加引发雪崩效应：

1. 激进的秒级轮询兜底：
   DEFAULT_REPORT_AUTO_REFRESH_SECONDS 与前端 DEFAULT_AUTO_REFRESH_MS 默认为 1 秒。用户停留在报表页时，前端每隔 1 秒即发起一次 /api/stats/summary。
2. 报表后端全量反序列化庞大明细：
   在 usage_summary 内部计算缓存命中率（cache_rates）与 24 小时整点趋势（cache_trend_24h）时，硬编码调用了 sql::select_between(conn, now - SUMMARY_WINDOW_MS, now, true)，将过去 7 天内的全部明细整行全量捞出（包含 attempt_details、sensitive_hits 等每条记录几 KB 至十几 KB 的重试大 JSON 文本），单次反序列化数万条大记录耗时 1~2 秒并大量占用内存与持有读锁。
3. 读锁堆叠与雪崩：
   由于单次后端查询耗时（1~2 秒）超过了前端的轮询周期（1 秒），新请求在上一轮尚未结束时密集到达，在 SQLite 上串行持锁排队堆叠，引发 CPU 满载与假死。
4. 缺乏复合索引：
   现有索引仅有 idx_requests_ts，对于 WHERE ts >= ? AND ts <= ? AND is_test = 0 范围查询，无法利用索引过滤测试数据，仍需逐行回表检查。

修法

1. 调整默认自动刷新间隔：
   • 将 DEFAULT_REPORT_AUTO_REFRESH_SECONDS 与前端 DEFAULT_AUTO_REFRESH_MS 默认值由 1 秒调整为合理的 30 秒，从源头杜绝高频请求堆叠。
2. 精简报表查询指标（CacheMetricEntry）：
   • 新增专属精简结构 CacheMetricEntry，在 sql::select_cache_metrics_between 中只投影 ts, prompt_tokens, total_tokens, cache_read_tokens, model, upstream_model 6 列标量字段；
   • 彻底跳过 attempt_details、sensitive_hits、route、error 等大文本字段的反序列化，内存分配减少 90% 以上，查询速度提升数十倍。
3. 补齐聚合复合索引（schema v15）：
   • 补充 idx_requests_summary (is_test, ts, row_id) 复合索引；
   • 使得报表时间范围查询能够直接通过索引完成过滤与有序扫描，消除全表扫描与文件排序。
4. 重建前端产物：
   • 重新构建 ui/islands/ui.js，确保前端产物与源码严格同源，满足 frontend-artifacts CI 门禁。

验证

• 前端产物通过 tsc --noEmit && vite build 重新编译，无类型错误；
• 实测 26,000+ 条真实生产请求数据下，报表数据接口查询耗时从原来的 1500ms~3000ms 大幅降低至 50ms 以内；
• 避免了高频堆叠，CPU 占用恢复平稳。