# 慢日志分析分步骤提示词

以下每条提示词均可直接复制粘贴，无需修改任何内容。Agent 会在需要时主动向你索取信息。

---

## 第一步：启动分析

```text
请使用 PostgreSQL Production DBA 智能体和 postgresql-log-analysis skill，帮我分析一次生产数据库性能事故。

在开始之前，请依次向我确认以下信息，每项我会逐一回答：
1. PostgreSQL 版本（主版本号即可，如 14、15、16）
2. 事故时间窗口和时区
3. 主要症状（CPU 高 / 延迟飙升 / 连接数暴涨 / 其他）
4. 业务类型和大致读写比例
5. 事故前是否有发布、DDL 变更、批任务或流量突增

确认完毕后等我发慢日志，不要提前开始分析。
```

---

## 第二步：让 Agent 跑脚本并分析

```text
背景信息已告知。日志文件已脱敏（密码、手机号、订单号、内网 IP 均已替换），请告诉我你需要哪个路径的文件，或者直接告诉我你能访问工作区里的哪些文件。

拿到路径后请执行：

python3 .trae/skills/postgresql-log-analysis/scripts/parse_postgres_slowlog.py \
  <日志路径> \
  --top 30 \
  --min-duration 100

执行完毕后，如果我有 pg_stat_statements 数据，请给我看你需要的查询语句，我去数据库跑完把结果贴给你。

两份材料都拿到后再开始根因分析，分析要求：
1. 识别对 CPU 贡献最大的指纹，按 total_ms 排序，calls 高但 mean_ms 低的也要关注。
2. 对 Top 3 指纹逐一说明：是什么操作、为什么慢、为什么在这个时间窗口爆发。
3. 区分根因和伴随症状，不要把因 CPU 高而被动变慢的查询也列为根因。
4. 证据不足时明确列出缺什么，不要猜测。

输出格式：结论 → 证据 → 主要发现 → 建议动作（分级）→ 需要补充的信息 → 验证方式。
```

---

## 第三步：深挖高嫌疑指纹

```text
请针对你认为最可疑的那个指纹深入分析。

你需要哪些额外信息，请列出清单，我逐项提供：
- 完整 SQL（脱敏版）
- 表结构和索引定义（\d tablename 输出）
- 表统计（行数、死元组比例、上次 vacuum/analyze 时间）
- 执行计划（我会在 replica 上用 EXPLAIN (BUFFERS, VERBOSE) 获取，不带 ANALYZE）

列完后等我逐项回答，拿齐材料再分析。分析时请回答：
1. 执行计划走了哪个索引或全表扫描，为什么？
2. shared_blks_read 和 shared_blks_hit 哪个高，说明什么？
3. 有没有 temp_blks_written，如有则 sort/hash spill 发生在哪一步？
4. 这条 SQL 慢的根本原因是什么？
```

---

## 第四步：给出分级解决方案

```text
基于以上分析，请给出完整的分级解决方案。

safe-now（立即可执行，零风险）：
- 现在应该观察哪些实时指标确认问题是否还在持续？
- 有没有可以限流或降级的业务开关？

low-risk（低峰期执行，影响可控）：
- 是否需要对某张表执行 ANALYZE 更新统计信息？
- 是否可以改写 SQL 降低扫描行数（加 LIMIT、拆分查询、消除 N+1）？
- 是否可以在应用层增加缓存或合并批量请求？

requires-change-window（需要变更窗口，有锁或停写风险）：
- 如果需要加索引，给出完整的 CREATE INDEX CONCURRENTLY 语句，说明预期效果和写放大代价。
- 如果需要改表结构或分区，说明迁移路径和回滚方案。

每条建议注明：预期效果、风险点、验证方式、回滚或停止条件。
```

---

## 第五步：验证与收尾

```text
方案已执行，请帮我做验证和复盘。

请先问我：
1. 执行了哪些操作，完成时间是？
2. 当前 CPU、P99 延迟、连接数各变化了多少？
3. pg_stat_statements 里该指纹的 mean_exec_time 现在是多少？

我回答完后，请贴出你需要的新 EXPLAIN 查询，我去 replica 重新跑一遍。

拿到新执行计划后请确认：
1. 是否走了预期索引？
2. 有没有其他指纹因此变慢（计划回归）？
3. 这次事故留了哪些未解决的隐患，建议加入后续 backlog？
```

---

## 快速追问模板

以下单句可在任意步骤直接追加发送：

| 目的 | 直接发送这句话 |
|------|----------------|
| 聚焦 CPU 根因 | 重点分析对 CPU 贡献最大的指纹，按 total_ms 排序，calls 高但 mean_ms 低的也要关注 |
| 排除锁干扰 | 先判断这些慢查询是真的执行慢还是在等锁，请先看 wait_event_type 和 wait_event |
| 区分读写压力 | 对比 shared_blks_read 和 shared_blks_hit，判断瓶颈在 CPU 计算还是 I/O 读取 |
| 排查 temp file 溢写 | 检查 temp_blks_written 和日志里的 temporary file 记录，定位 sort/hash spill 指纹 |
| 排查统计信息问题 | 该 SQL 是否因统计信息过期导致计划选错，上次 autoanalyze 是什么时候 |
| 只要保守建议 | 只给 safe-now 操作，requires-change-window 的方案先不要说，等我确认后再继续 |
| 证据不足时 | 如果现有材料不够，先列出还缺哪些信息，不要强行下结论 |