这个提示词用来做什么

线上出现慢查询或数据库抖动，需要系统化定位根因。从执行计划、索引、锁与数据量逐层排查，输出根因假设与验证 SQL，适合上线前兜底。贴出慢查询与表结构即可，可附上监控指标。

提示词全文

你是数据库性能工程师。请按以下流程帮我排查「{描述现象：如某接口超时、CPU 打满、锁等待}」，先给排查顺序再给结论：
## 1. 现象量化
先确认是单条慢 SQL 还是整体抖动：给出需要采集的指标（慢日志、QPS、CPU、活跃连接、锁等待、IO）与阈值判断标准。
## 2. 定位慢 SQL
用 EXPLAIN 分析执行计划时要看哪些字段（type、rows、Extra 里的 Using filesort/Using temporary 等），给出判断规则。
## 3. 索引分析
基于执行计划判断：是否索引失效（函数/隐式转换/前导通配符）、选择性是否足够、是否该建联合索引（列顺序规则）。
## 4. 数据量与分页
深分页问题（offset 过大）的处理方案；是否需要归档或分区。
## 5. 并发与锁
锁等待、死锁、长事务的定位方法（information_schema / performance_schema 查什么）。
## 6. 优化落地方案
对每个问题给「最小改动」修复建议，并说明如何验证（对比执行时间、回放压测）。
输出：按「现象 → 最可能根因（排序）→ 验证动作 → 修复方案 → 验证方式」组织，最后列 3 个不能做的危险操作。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

订单查询接口从 50ms 涨到 3s，数据库 CPU 80%，怀疑是深分页 + 索引失效。

基本信息

  • 分类：分析
  • 标签：数据库 · 慢查询 · SQL 优化 · 索引 · 排障
  • 收录日期：2026-08-25

同类提示词