SQL 查询生成 Prompt：从自然语言到优化 SQL

用法

把表结构（DDL）和你的需求描述粘进来，AI 会生成带注释的 SQL + 性能建议。

什么时候用 / 别用

一条硬纪律：任何 AI 生成的写操作，都先在事务里跑 SELECT 看命中范围，再决定执不执行。 BEGIN; … ROLLBACK; 是你的安全网。

Prompt

你是一个资深 DBA。请根据以下表结构，把我描述的需求转成 SQL 查询。

## 表结构

{{粘贴你的 CREATE TABLE 语句，或表名+字段说明}}

## 需求

{{用自然语言描述你要查什么，比如"查上个月销售额前十的用户"}}

## 要求

1. 生成标准 SQL（MySQL / PostgreSQL，说明你选了哪个方言）
2. 所有字段名用反引号包裹
3. 每个关键步骤加注释说明逻辑
4. 如果需要 JOIN，说明为什么选这种 JOIN 类型
5. 如果查询可能慢，给出索引建议
6. 如果需求有歧义，先列出你的假设，再给 SQL

## 输出格式

### 假设（如果有歧义）
- 假设 1：...
- 假设 2：...

### SQL
```sql
-- 你的 SQL
```

### 索引建议（如果需要）
- `CREATE INDEX idx_xxx ON table(column)` — 理由

### 性能说明
- 预估扫描行数：...
- 是否走索引：...

示例对话

输入： 表结构：orders(id, user_id, amount, created_at, status) 需求：查上个月每个用户的总消费，取前 10 名

输出：

假设

• "上个月"指自然月（非最近 30 天）
• 只统计已支付订单（status = 'paid'）

SQL

SELECT
  user_id,
  SUM(amount) AS total_spent
FROM `orders`
WHERE `status` = 'paid'
  AND `created_at` >= DATE_FORMAT(DATE_SUB(CURDATE(), INTERVAL 1 MONTH), '%Y-%m-01')
  AND `created_at` < DATE_FORMAT(CURDATE(), '%Y-%m-01')
GROUP BY `user_id`
ORDER BY `total_spent` DESC
LIMIT 10;

索引建议

• CREATE INDEX idx_status_created ON orders(status, created_at) — 覆盖时间范围筛选

性能说明

• 走 idx_status_created 索引，避免全表扫描
• GROUP BY user_id 需要临时表排序，数据量大时考虑分页

为什么有效

• 给表结构（DDL）而不是表名：AI 不知道列名就会编，编出来的 SQL 能跑但查的是错的字段。
• 要求说明索引影响：绝大多数慢查询不是 SQL 写法问题而是索引没命中，不显式要求，AI 不会主动看执行计划。
• 要求给边界条件：空结果、NULL 语义、时区——这三类是 SQL 输出与预期不符的高频来源。

验收判据：四条过了才算能上

1. 执行计划实测 —— 跑 EXPLAIN ANALYZE，确认走的是预期索引，没有意外的 Seq Scan 落在千万级大表上。
2. 边界语义确认 —— 空结果集、NULL 的三值逻辑、时区（timestamptz 还是本地时间）、「上个月」是自然月还是滚动 30 天。这四类是 SQL 结果与预期不符的高频来源。
3. 结果行数对得上 —— 用一个你自己手算得出数字的小样本先跑一遍，对不上说明 JOIN 扇出或多对多关系被处理错了。
4. 写操作先只读预演 —— UPDATE / DELETE 先写成 SELECT count(*) 跑一遍，确认命中行数在预期量级。

第 3 条最常被跳过，也最容易出事。 AI 写的 JOIN 在语义上「说得通」，但如果关联键不是唯一的，结果集会被静默放大——查出来的总数看着合理，实际每一行都被重复计了。

进阶（自动化）

生成后先在只读副本上验证执行计划，再上生产：

# 只看计划不执行
pnpm exec prisma db execute --url "$READONLY_URL" \
  --stdin <<< "EXPLAIN ANALYZE <生成的 SQL>"

关注 Seq Scan 是否落在预期索引上；长期方案见 Prompt 缓存 之外更直接的手段——加索引与改查询结构。

四个变体：按你的目的选一个

接进管道（headless）

# 把 DDL 喂进去，直接拿到带执行计划说明的 SQL
cat schema.sql | claude -p "按 /prompts/sql-generation 的模板生成查询，
采用变体 B（性能优化），方言 PostgreSQL，并说明每条索引建议的代价"

方言必须在管道命令里写死。AI 默认会给你最通用的写法，而 MySQL 与 PostgreSQL 在日期函数、字符串拼接、LIMIT 语法上的差异足以让 SQL 直接报错。

反例（AI 默认会写的烂版本）

默认输出：SELECT * FROM orders WHERE created_at > '2026-01-01'——没走索引提示、没处理 created_at 为 NULL 的行、也没说时区是 UTC 还是本地。

加了 prompt 之后：明确 created_at 上有 B-tree 索引故可走 range scan；WHERE created_at >= '2026-01-01'::timestamptz AND created_at IS NOT NULL；并提示「若要用本地时区，先确认列类型为 timestamptz」。

延伸阅读

• 性能优化 Prompt — 慢查询定位与索引优化
• Regex 生成 Prompt — 同样"自然语言 → 代码"的套路
• Cursor + MCP 操作数据库 — 让 AI 直接连库查 schema、跑 EXPLAIN