编程开发 编辑复核
SQL 查询性能评审
结合查询、表结构、索引、数据量和执行计划判断性能风险，避免盲目加索引。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名数据库性能评审员。请根据实际查询和执行证据分析性能，不要仅凭 SQL 外观断言一定慢或一定需要索引。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 查询目标、返回规模和调用频率
2. 表结构、数据分布和已有索引
3. 执行计划、排序、扫描和锁风险
4. 改写或索引方案及副作用
5. 基准、线上观测和回滚条件
输入变量：
- SQL 查询（{{query}}）：提供脱敏 SQL、参数范围和返回字段。
- 表结构（{{schema}}）：提供相关字段、类型、主键和索引。
- 执行证据（{{plan}}）：提供 EXPLAIN、慢查询或 trace。
- 数据规模（{{scale}}）：提供行数、增长速度和并发。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 在接近生产的数据分布上比较优化前后，避免用小样本得出结论。
- 索引会增加写入和存储成本，必须写出副作用。
WHEN IT FITS
适用判断
适合这些情况
- 查询结果正确但执行慢，需要找出慢在哪。
- 你能提供执行计划、表的行数和现有索引。
- 需要判断该加索引还是改写查询。
换个做法更好
- 你怀疑查询结果不对：用《SQL 查询正确性与性能检查》先确认正确性。
- 数据量很小：优化收益有限。
- 你没有执行计划：性能评审全靠猜。
FAILURE MODES
常见翻车与修正
- 模型建议加索引，但没考虑写入变慢和已有索引的重复。
要求列出现有索引，检查建议的索引是否与已有的前缀重复，并说明对写入的影响。
- 分析基于模型想象的执行计划，不是你的实际情况。
把 EXPLAIN 输出粘进输入，要求所有结论引用其中的具体行，没有依据的标为推测。
- 改写后的查询和原查询结果不一致。
要求每个改写方案都说明它与原查询在结果上是否完全等价，不等价的明确指出差异场景。
ACCEPTANCE
怎么判断输出合格
- 分析引用了你提供的执行计划，不是凭空推断。
- 索引建议检查了与现有索引的重复和写入影响。
- 改写方案说明了与原查询的结果等价性。
- 给出了验证优化效果的测量方式。
SAFETY BOUNDARY
使用边界
- 查询和表结构里可能含业务敏感的字段命名，粘贴前评估是否需要脱敏。
- 建索引会占用空间并拖慢写入，模型建议的索引要在预发环境实测收益后再上生产。