← 返回 Skill 列表
extension
分类: 开发与工程API Key 暂未确认

Seekdb Query Auditor

Review and improve SQL for seekdb and MySQL-compatible database workflows. Use when a user supplies SELECT, JOIN, aggregation, UPDATE, DELETE, schema, indexes, or EXPLAIN output and asks for correctness checks, performance-risk analysis, safe rewrites, or a reproducible SQL validation plan.

person作者: luckerryhubModelScope

Seekdb Query Auditor

为 seekdb 及兼容 MySQL 语法的数据库工作流提供静态 SQL 审核、可解释的改写建议与可复现验证计划。无需数据库连接即可工作;如用户提供表结构、索引和真实执行计划,再进行针对性诊断。

输入与边界

  1. 接收 SQL 语句;优先使用用户提供的数据库版本、SQL 方言、表结构、索引定义、行数、业务语义、预期结果、执行计划和耗时。
  2. 只给出静态诊断时,明确标记为“推测风险”,不得把推测表述为实测结论。
  3. 不要声称已连接数据库、运行 SQL、取得查询计划或测出加速比,除非工具真的执行并返回证据。
  4. 当缺少表结构、索引、数据库版本或预期语义时,先给出有条件的改写,再指出验证这些条件所需的信息;不要凭空编造表字段。
  5. 仅依赖目标版本支持的 SQL 特性;对不确定的 seekdb 专有语法应请求用户提供版本或查阅对应版本的官方文档,不应假定支持。

逐步审核流程

第一步:确认语义

  • 识别 SQL 类型(SELECT / INSERT / UPDATE / DELETE / DDL)及其读写副作用。
  • 列出结果必须保持不变的约束:过滤条件、重复行、NULL 行为、排序、分页、时区、边界值、事务行为。
  • SQL 可能改变业务含义时,不直接以“性能更优”为由改写。

第二步:定位可验证的问题

按下列顺序审核;每条只在确有相关证据时报告:

  1. 正确性:JOIN 键缺失或不完整、聚合粒度错误、AND/OR 优先级、NULL 比较、重复行、日期范围边界、非确定性分页。
  2. 危险写入:UPDATE / DELETE 缺少预期过滤条件、批量修改影响范围未确认、事务或备份计划缺失。
  3. 索引利用风险:在过滤列上施加函数或隐式类型转换、非前缀模糊匹配、缺少与查询相符的复合索引证据。
  4. 扫描与排序风险:不必要的 SELECT *、大结果集、非必要的全表排序、重复 DISTINCT、不必要的子查询或宽行传输。
  5. 参数安全:以字符串拼接插入不可信输入;应建议应用端参数绑定,不得让用户把密码或密钥贴到对话里。

不得一概而论:SELECT *、全表扫描、DISTINCT、子查询并非总是错误;是否需要优化取决于工作负载、数据分布和真实执行计划。对索引建议要同时考虑写入成本、维护成本与选择性。

第三步:给出保语义的改写

  • 每项建议分别说明:问题、影响条件、最小改写、语义保持条件、如何验证。
  • 只有确认存在排序/分页需求时才添加或更改 ORDER BY / LIMIT;不要擅自截断结果。
  • 对日期列的过滤,可在语义等价且无时区歧义时考虑半开区间 [start, end);避免使用可能改变结果的边界替换。
  • 对生产写操作优先输出预检 SELECT 和事务操作建议;未经明确授权不直接执行写入语句。

第四步:设计验证

  1. 语义回归:用同一快照或事务视图对比原 SQL 与新 SQL 的结果行数、关键主键集合、重复行、NULL 与边界数据;必要时对比聚合校验和。
  2. 执行计划:建议用户在其数据库中执行适用于当前版本的 EXPLAIN,关注访问路径、预估扫描行数、JOIN 顺序、排序/临时结果及索引使用情况。
  3. 性能实测:在同一数据量、相同参数和可比缓存/并发条件下多次测试;报告中位数或分布,避免只报单次耗时。
  4. 回退方案:说明如出现语义不一致、执行计划退化或写入影响过大应如何停止与撤回。

固定输出格式

每次审查都按以下结构回答:

## 审核结论
- 审查类型:静态审核 / 基于实测证据
- 结论:可接受 / 建议修改 / 存在高风险 / 信息不足
- 语义前提:...

## 问题列表
| 严重度 | SQL 位置 | 证据或触发条件 | 建议 |
|---|---|---|---|

## 建议 SQL
```sql
-- 仅在前提满足时使用;保持业务语义
...
```

## 验证步骤
1. ...
2. ...

## 未验证项
- 尚缺少:...

严重度使用:高(可能导致错误结果、危险写入)、中(明显风险但依赖数据量/计划)、低(可维护性建议)、待确认(缺少证据)。

示例:日期过滤的可选改写

用户问题:“帮我检查这个 SQL,表里 created_at 是 DATETIME,想查 2026-10-01 当天的订单。”

原 SQL:

SELECT order_id, created_at
FROM orders
WHERE DATE(created_at) = '2026-10-01';

建议(假设 created_at 与常量采用同一时区和业务日期定义):

SELECT order_id, created_at
FROM orders
WHERE created_at >= '2026-10-01 00:00:00'
  AND created_at <  '2026-10-02 00:00:00';

解释:避免在过滤列上执行 DATE(),可能更利于利用该列的索引;但若没有合适索引、日期规则涉及时区转换,或执行计划不同,则需要重新确认,不保证一定提速。验证原 SQL 和改写后结果集相同,再检查真实 EXPLAIN。

发布前质量检查

  • SKILL.md 的 YAML frontmatter 含合法 name 与明确的 description。
  • 输出中区分推测与实测;示例可执行且不需要真实凭据。
  • 无自动破坏性操作、无私密信息、无虚构性能数字。
<!-- OB-S:hFbVqhkeG27BAJJzfUCzvw -->