编程开发 编辑复核
SQL 查询正确性与性能检查
检查查询的结果语义、边界、索引、锁和隐私风险，输出可用执行计划验证的建议。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名数据库查询评审员。请基于 schema、业务口径和 SQL，检查结果对不对与跑得是否安全，不要只给格式建议。
输出按 P0-P3 排序的问题：连接条件、重复行、空值、时间区间、时区、权限、全表扫描、排序/分页、锁和敏感字段暴露。每项说明证据、触发条件、影响、改写方向和验证 SQL。
最后给出需要的 EXPLAIN/EXPLAIN ANALYZE、测试数据边界和上线前后指标。没有 schema 或业务口径时不要猜列含义。
SQL：{{sql}}
Schema：{{schema}}
业务口径：{{business_definition}}
运行环境：{{environment}}HOW TO USE
使用说明
- 先在脱敏副本执行 EXPLAIN 和边界样本，再考虑进入报表或接口。
- 结果正确性优先于速度；不能为了性能删掉去重、权限或时间边界。
WHEN IT FITS
适用判断
适合这些情况
- 查询逻辑复杂，担心结果不对而不是跑得慢。
- 涉及多表关联、聚合或子查询，边界情况容易出错。
- 你能提供表结构和数据量级。
换个做法更好
- 查询结果是对的，只是慢：用《SQL 查询性能评审》。
- 查询很简单：直接跑一下比评审快。
- 你没有表结构：模型无法判断关联字段和空值行为。
FAILURE MODES
常见翻车与修正
- 模型没注意到 LEFT JOIN 后的 WHERE 条件把外连接变成了内连接。
这是最常见的静默错误。要求逐个 JOIN 检查过滤条件的位置，并说明放在 ON 和 WHERE 的结果差异。
- 忽略了 NULL 参与比较和聚合时的行为。
要求专门检查涉及 NULL 的字段：比较、COUNT、SUM 和 NOT IN 的行为，逐条说明预期。
- 评审结论是「看起来没问题」，没有可验证的依据。
要求给出验证查询——用小数据集能验证正确性的对照 SQL，而不是口头结论。
ACCEPTANCE
怎么判断输出合格
- 逐个检查了 JOIN 类型和过滤条件的位置。
- 涉及 NULL 的字段行为都单独说明了。
- 给出了可以实际跑的验证查询。
- 指出的问题都基于你提供的表结构，不是通用告诫。
SAFETY BOUNDARY
使用边界
- 不要提供生产连接信息或未经脱敏的用户数据。
- 涉及生产写入、删除或权限变更时停止生成执行命令，转交数据库负责人。