适合什么场景
写 SQL 的痛点不是语法，而是**想清楚口径**：什么叫"最近 30 天"？"已支付"包含退款吗？金额按什么时间归集？
这条提示词的价值不只是生成语句，而是**把口径问题提前暴露出来**——它要求 AI 先说明假设，再给 SQL。很多数据错误的根源，就是口径没对齐就开始写查询。
这条提示词适合：数据分析、运营取数、报表开发、临时排查问题。
提示词原文
你是数据库工程师。请根据以下需求编写 SQL 语句：
数据库类型：{数据库} 表结构：{表结构} 我要的数据：{需求}
要求： 1. 给出完整的 SQL 语句，可直接复制执行 2. 每段子查询或关键子句后面用注释说明它在做什么 3. 说明这条语句的执行逻辑（先做什么、再做什么） 4. 指出可能的性能问题，并给出优化建议（索引、改写方式） 5. 给出 2-3 个变体（如换成按周统计、加上同比环比、排除某些数据） 6. 说明可能踩的坑（如 NULL 处理、除零、时区、字符串与数字隐式转换） 7. 说明结果会返回哪些字段、大概什么形态 8. 如果需求描述有歧义，先列出你的理解和假设，再给 SQL ```
变量怎么填
- **数据库**：MySQL 8.0 / PostgreSQL 15 / SQLite。**版本很重要**——窗口函数 8.0 才支持，写错版本语法直接报错
- **表结构**：把建表语句或字段清单贴进去，**字段名要准确**。有索引也一并说明
- **需求**：用大白话描述，**把口径写清楚**。写"最近30天"时补一句"按 created_at 算"，避免歧义
生成效果示例
-- 需求理解与假设： -- 1. "最近30天" 指 created_at >= 当前时间 - 30 天 -- 2. "已支付" 指 status = 'paid'（不含 refunded / cancelled） -- 3. 按用户汇总，金额求和，降序取前 20
SELECT user_id, SUM(amount) AS total_amount, -- 汇总已支付金额 COUNT(*) AS order_count -- 顺便给出订单数 FROM orders WHERE status = 'paid' -- 只要已支付 AND created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) -- 最近 30 天 GROUP BY user_id ORDER BY total_amount DESC LIMIT 20;
-- 执行逻辑： -- ① 用 WHERE 先过滤（状态 + 时间）→ 数据量大幅减少 -- ② 按 user_id 分组求和 -- ③ 排序取前 20
-- 性能建议： -- 建复合索引 (status, created_at)： -- CREATE INDEX idx_status_created ON orders(status, created_at); -- 若 orders 表很大，可先按时间分区，避免全表扫描
-- 可能的坑： -- · amount 为 NULL 时 SUM 会忽略，若需计入 0 要用 IFNULL(amount,0) -- · created_at 若是字符串类型，比较会走隐式转换，索引失效 -- · NOW() 受时区影响，跨时区业务要用 UTC_TIMESTAMP() 统一 ```
**变体一：加上月环比** ```sql SELECT user_id, SUM(CASE WHEN created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) THEN amount END) AS cur_amount, SUM(CASE WHEN created_at >= DATE_SUB(NOW(), INTERVAL 60 DAY) AND created_at < DATE_SUB(NOW(), INTERVAL 30 DAY) THEN amount END) AS prev_amount FROM orders WHERE status = 'paid' AND created_at >= DATE_SUB(NOW(), INTERVAL 60 DAY) GROUP BY user_id HAVING cur_amount > 0; ```
**变体二：按周统计趋势** ```sql SELECT YEARWEEK(created_at, 1) AS week, SUM(amount) AS week_amount FROM orders WHERE status = 'paid' AND created_at >= DATE_SUB(NOW(), INTERVAL 12 WEEK) GROUP BY week ORDER BY week; ```
变体与调整
- **要更简单**：加"用最基础的语法，不用 CTE 和窗口函数，兼容老版本"
- **要更高效**：加"针对千万级数据量优化，优先考虑索引利用和分区裁剪"
- **要可复用**：加"把变化的日期区间提取成变量，方便改参数"
- **要做数据校验**：加"额外给一条校验 SQL，用于核对汇总结果是否与明细一致"
- **要兼容多库**：加"同时给出 MySQL 和 PostgreSQL 两个版本，标注语法差异"
常见问题
**Q：跑出来的数跟报表对不上？** A：99% 是**口径不一致**。先查三件事：时间字段是不是同一个、状态筛选是否一致、有没有漏掉或重复 JOIN。加"给一条明细核对 SQL，用于逐条验证"。
**Q：查询很慢，几十秒不返回？** A：让 AI 加"分析这条 SQL 的索引利用情况，给出 EXPLAIN 的关键关注点"。常见原因是 WHERE 字段没索引、或对字段做了函数运算（如 `DATE(created_at)`）。
**Q：不敢在生产库跑？** A：**先加 LIMIT 试跑**。加"给一个带 LIMIT 10 的安全试跑版本"。跑对了再放开。