AI的提示词专栏：Prompt 驱动的 SQL 生成与查询优化

一、引言：SQL 生成与优化的痛点与 Prompt 解决方案

在数据驱动决策的时代，SQL（结构化查询语言）作为操作关系型数据库的核心工具，被广泛应用于数据提取、分析与报表生成。然而，SQL 编写与优化却长期面临两大核心痛点：

• 入门门槛高：非技术人员（如业务分析师、运营）需掌握复杂语法规则（如多表关联、子查询、窗口函数）才能生成有效查询，往往需要依赖开发团队支持，导致数据需求响应延迟；
• 优化难度大：即使是资深开发者，也需通过分析执行计划、调整索引、重构语句等方式优化查询性能，过程耗时且依赖经验，尤其面对千万级以上数据量时，低效 SQL 可能导致数据库过载。

Prompt 技术的出现为解决这些痛点提供了全新思路。通过设计精准的提示词，可驱动大语言模型（LLM）自动生成符合需求的 SQL 语句，并基于数据库特性输出优化建议，实现“自然语言→SQL→优化 SQL”的全流程自动化。本章将从基础原理、实战案例、进阶技巧三个维度，系统讲解 Prompt 驱动的 SQL 生成与查询优化方法，帮助不同技术背景的读者快速掌握这一高效工具。

二、Prompt 驱动 SQL 生成的核心原理

要让 LLM 精准生成 SQL，需先理解其背后的逻辑：LLM 通过学习海量文本数据（含 SQL 语法规则、业务场景案例），可将自然语言描述的“数据需求”转化为结构化的 SQL 语句。而 Prompt 的核心作用，是为 LLM 提供“需求边界”与“执行约束”，避免生成歧义或无效代码。其核心原理可拆解为以下三点：

（一）需求转化：从自然语言到 SQL 逻辑的映射

LLM 生成 SQL 的本质是“语义理解→逻辑拆解→语法转换”的过程。例如，当用户提出“查询 2024 年 1-3 月北京地区的订单金额大于 1000 元的订单数量”时，LLM 需先拆解需求要素：

• 数据范围：订单表（隐含）、时间范围（2024-01-01 至 2024-03-31）、地区（北京）；
• 筛选条件：订单金额 > 1000 元；
• 统计目标：订单数量（COUNT 函数）。

此时，Prompt 需明确这些要素，帮助 LLM 建立“自然语言描述”与“SQL 子句”的对应关系——如“时间范围”对应 WHERE order_time BETWEEN '2024-01-01' AND '2024-03-31'，“统计目标”对应 SELECT COUNT(order_id)。

（二）约束注入：让 SQL 符合业务与技术规则

未加约束的 Prompt 易导致 SQL 不符合实际场景，例如：

• 表名/字段名与实际数据库不一致（如用户说“订单金额”，实际字段为 order_amount）；
• 未考虑数据类型（如日期字段用字符串比较，导致查询错误）；
• 忽略业务逻辑（如“有效订单”需排除取消状态，字段 order_status = 1）。

因此，Prompt 需提前注入“约束信息”，包括：数据库表结构（表名、字段名、数据类型）、业务规则（筛选条件、计算逻辑）、语法规范（如 MySQL/PostgreSQL 差异），确保生成的 SQL 可直接执行。

（三）示例引导：Few-Shot Prompt 提升生成精度

对于复杂需求（如多表关联、嵌套子查询），仅靠自然语言描述易让 LLM 产生歧义。此时，通过 Few-Shot Prompt（提供 1-3 个“需求→SQL”示例），可让 LLM 快速学习同类需求的处理逻辑，显著提升生成精度。例如，在生成“按用户等级统计平均订单金额”的 SQL 前，先提供“按地区统计订单数量”的示例，LLM 会参考示例中的分组逻辑（GROUP BY）与统计函数（A VG），避免语法错误。

三、Prompt 驱动 SQL 生成的实战案例

根据需求复杂度，可将 Prompt 分为“基础型”“进阶型”“复杂型”三类，以下结合不同行业场景提供实战案例，并标注关键技巧。

（一）基础型 Prompt：单表查询与简单统计

适用场景：无需多表关联，仅需对单个表进行筛选、排序、基础统计（如 COUNT、SUM、A VG），常见于业务运营的日常数据查询。

案例1：电商运营需求——查询月度热销商品

需求描述：“从商品销售表（sales_product）中，查询 2024 年 5 月销量排名前 10 的商品，需显示商品 ID（product_id）、商品名称（product_name）、销量（sales_quantity），按销量降序排列。”

精准 Prompt 设计：

请作为 SQL 工程师，基于以下信息生成 MySQL 语法的 SQL 语句：
1. 数据库表结构：
   - 表名：sales_product
   - 字段：product_id（INT，商品唯一ID）、product_name（VARCHAR，商品名称）、sales_quantity（INT，销量）、sale_date（DATE，销售日期）
2. 需求：查询 2024 年 5 月销量排名前 10 的商品
3. 输出要求：
   - 显示字段：product_id、product_name、sales_quantity
   - 排序规则：按 sales_quantity 降序
   - 结果限制：仅返回前 10 条数据
4. 语法规范：需兼容 MySQL 8.0，避免使用数据库特有函数

预期输出（SQL 语句）：

SELECT product_id,product_name,sales_quantityFROM sales_productWHERE sale_date BETWEEN '2024-05-01' AND '2024-05-31'-- 筛选 2024 年 5 月数据ORDER BY sales_quantity DESC-- 按销量降序LIMIT 10;-- 取前 10 条

技巧点分析：

• 明确表结构：Prompt 中列出表名、字段名及数据类型，避免 LLM 猜测字段（如误将“销量”写为 quantity 而非 sales_quantity）；
• 时间范围精准化：用 BETWEEN...AND 明确日期范围，而非模糊描述“5 月”，避免生成 MONTH(sale_date) = 5（可能包含非 2024 年的数据）；
• 指定数据库类型：标注“MySQL 8.0”，确保 LLM 生成 LIMIT（而非 PostgreSQL 的 FETCH FIRST 10 ROWS ONLY）。

（二）进阶型 Prompt：多表关联与复杂统计

适用场景：需关联 2-3 个表（如订单表、用户表、商品表），结合多条件筛选与复杂统计（如分组后过滤、窗口函数），常见于数据分析场景。

案例2：金融风控需求——统计各用户的逾期贷款金额

需求描述：“从贷款表（loan_info）和用户表（user_info）中，关联查询 2023 年发放的贷款中，各用户的逾期贷款总金额。需显示用户 ID（user_id）、用户姓名（user_name）、逾期总金额（overdue_total），仅包含逾期金额大于 0 的用户。”

精准 Prompt 设计：

请生成 PostgreSQL 语法的 SQL 语句，需满足以下要求：
1. 数据库表结构：
   - 表1：loan_info（贷款信息表）
     字段：loan_id（INT，贷款ID）、user_id（INT，用户ID，关联 user_info 的 user_id）、loan_amount（DECIMAL(10,2)，贷款金额）、issue_date（DATE，发放日期）、overdue_amount（DECIMAL(10,2)，逾期金额）
   - 表2：user_info（用户信息表）
     字段：user_id（INT，用户唯一ID）、user_name（VARCHAR(50)，用户姓名）、user_level（VARCHAR(20)，用户等级）
2. 业务逻辑：
   - 关联条件：loan_info.user_id = user_info.user_id（内连接，仅保留有贷款记录的用户）
   - 时间筛选：2023 年发放的贷款（issue_date BETWEEN '2023-01-01' AND '2023-12-31'）
   - 统计逻辑：按用户分组，计算每个用户的逾期金额总和（命名为 overdue_total）
   - 结果筛选：仅保留 overdue_total > 0 的用户
3. 输出字段：user_id、user_name、overdue_total
4. 语法要求：使用显式 JOIN 语法，避免隐式关联；字段类型需匹配（如 DECIMAL 字段用 SUM 函数）

预期输出（SQL 语句）：

SELECT ui.user_id,ui.user_name,SUM(li.overdue_amount) AS overdue_total-- 统计用户逾期总金额FROM loan_info liINNER JOIN user_info ui ON li.user_id = ui.user_id-- 内连接用户表WHERE li.issue_date BETWEEN '2023-01-01' AND '2023-12-31'-- 筛选 2023 年贷款GROUP BY ui.user_id, ui.user_name-- 按用户分组（需包含非聚合字段）HA VING SUM(li.overdue_amount) > 0;-- 过滤逾期金额大于 0 的用户

技巧点分析：

• 显式关联与别名：用 INNER JOIN...ON 显式指定关联条件，并用 li（loan_info）、ui（user_info）作为表别名，提升 SQL 可读性；
• 分组与过滤逻辑：明确“先筛选行（WHERE），再分组统计（GROUP BY），最后过滤分组结果（HA VING）”的顺序，避免 LLM 将 overdue_total > 0 写入 WHERE 子句（语法错误）；
• 数据类型匹配：标注 overdue_amount 为 DECIMAL 类型，确保 LLM 使用 SUM 函数（而非 COUNT）进行统计。

（三）复杂型 Prompt：子查询、窗口函数与动态条件

适用场景：包含嵌套子查询、窗口函数（如排名、累计求和）或动态筛选条件（如按日期范围动态生成），常见于数据报表与深度分析场景。

案例3：互联网产品需求——用户行为漏斗分析

需求描述：“从用户行为表（user_beha vior）中，分析 2024 年 6 月的用户行为漏斗：访问（event_type = 'view'）→ 加购（event_type = 'add_cart'）→ 下单（event_type = 'order'）。需按日期分组，计算每个步骤的用户数、累计转化率（当前步骤用户数/访问用户数），并显示每日的漏斗数据。”

精准 Prompt 设计：

请生成兼容 SQL Server 的 SQL 语句，用于用户行为漏斗分析，具体要求如下：
1. 数据库表结构：
   - 表名：user_beha vior
   - 字段：user_id（VARCHAR(50)，用户唯一ID）、event_type（VARCHAR(20)，行为类型：view=访问、add_cart=加购、order=下单）、event_time（DATETIME，行为时间）、page_url（VARCHAR(255)，访问页面）
2. 业务逻辑：
   - 时间范围：2024 年 6 月（event_time BETWEEN '2024-06-01 00:00:00' AND '2024-06-30 23:59:59'）
   - 漏斗步骤：view（步骤1）→ add_cart（步骤2）→ order（步骤3）
   - 统计规则：
     ① 按日期（DATE(event_time)）分组，统计每日各步骤的独立用户数（去重，用 DISTINCT）；
     ② 计算转化率：步骤2转化率 = 步骤2用户数/步骤1用户数，步骤3转化率 = 步骤3用户数/步骤1用户数；
     ③ 转化率保留 4 位小数，用百分比格式显示（如 0.3567 → 35.67%）。
3. 输出字段：
   - date（日期，格式：YYYY-MM-DD）
   - view_user（访问用户数）
   - add_cart_user（加购用户数）
   - order_user（下单用户数）
   - add_cart_rate（加购转化率）
   - order_rate（下单转化率）
4. 技术要求：
   - 使用子查询或 CTE（公共表表达式）计算各步骤用户数，避免重复代码；
   - 转化率计算需处理分母为 0 的情况（用 NULLIF 函数），防止报错；
   - 日期格式用 CONVERT 函数统一为 'YYYY-MM-DD'。

预期输出（SQL 语句）：

WITH daily_beha vior AS (-- CTE：按日期和行为类型统计独立用户数SELECT CONVERT(VARCHAR(10), event_time, 23) AS date,-- 格式化日期为 YYYY-MM-DDevent_type,COUNT(DISTINCT user_id) AS user_count-- 独立用户数（去重）FROM user_beha viorWHERE event_time BETWEEN '2024-06-01 00:00:00' AND '2024-06-30 23:59:59'GROUP BY CONVERT(VARCHAR(10), event_time, 23), event_type)SELECT date,-- 提取各步骤用户数（无数据时显示 0）ISNULL(MAX(CASE WHEN event_type = 'view' THEN user_count END), 0) AS view_user,ISNULL(MAX(CASE WHEN event_type = 'add_cart' THEN user_count END), 0) AS add_cart_user,ISNULL(MAX(CASE WHEN event_type = 'order' THEN user_count END), 0) AS order_user,-- 计算转化率（处理分母为 0 的情况）CONVERT(VARCHAR, ROUND(ISNULL(MAX(CASE WHEN event_type = 'add_cart' THEN user_count END), 0) / NULLIF(MAX(CASE WHEN event_type = 'view' THEN user_count END), 0) * 100, 2)) + '%' AS add_cart_rate,CONVERT(VARCHAR, ROUND(ISNULL(MAX(CASE WHEN event_type = 'order' THEN user_count END), 0) / NULLIF(MAX(CASE WHEN event_type = 'view' THEN user_count END), 0) * 100, 2)) + '%' AS order_rateFROM daily_beha viorGROUP BY dateORDER BY date;

技巧点分析：

• CTE 简化逻辑：通过 daily_beha vior 公共表表达式先统计“日期+行为类型”的用户数，避免后续重复写 COUNT(DISTINCT user_id)，提升 SQL 可维护性；
• 条件聚合：用 CASE WHEN 提取各步骤用户数（如 MAX(CASE WHEN event_type = 'view' THEN user_count END)），实现“一行显示多步骤数据”的漏斗格式；
• 异常处理：用 NULLIF(..., 0) 处理“访问用户数为 0”的情况，避免除法报错；用 ISNULL(..., 0) 将无数据的步骤用户数显示为 0，符合业务认知。

四、Prompt 驱动的 SQL 查询优化实战

生成可执行的 SQL 只是第一步，当数据量达到百万级以上时，低效 SQL 可能导致查询耗时过长（如超过 10 秒），甚至引发数据库锁表。此时，通过 Prompt 驱动 LLM 输出优化建议，可快速提升查询性能。以下从“性能诊断”“优化方向”“实战案例”三方面展开。

（一）SQL 性能问题的常见原因

在设计优化 Prompt 前，需先明确 LLM 需识别的核心性能瓶颈，主要包括：

• 全表扫描：未建立索引或索引失效（如使用 NOT IN、函数操作索引字段），导致数据库遍历整张表；
• 关联效率低：多表关联时使用 LEFT JOIN 替代 INNER JOIN（返回数据量过大），或关联字段未加索引；
• 排序/分组耗时：ORDER BY/GROUP BY 的字段未加索引，导致数据库需额外进行“文件排序”；
• 子查询冗余：嵌套子查询重复执行（如在 WHERE 子句中使用 (SELECT ...)），未用 JOIN 优化；
• 数据量过大：未筛选不必要的字段（如用 SELECT *）或未限制结果集（如缺失 LIMIT）。

（二）SQL 优化 Prompt 的设计要点

要让 LLM 精准输出优化建议，Prompt 需包含以下关键信息：

• 原始 SQL 语句：提供待优化的完整 SQL，包括表名、字段、关联逻辑；
• 数据库环境：指定数据库类型（MySQL/PostgreSQL/SQL Server）、版本、表数据量（如“order 表 500 万行”）、索引情况（如“order_id 为主键，无其他索引”）；
• 性能现状：描述当前查询耗时（如“执行时间 15 秒”）、执行计划关键信息（如“Using filesort”“Using temporary”）；
• 优化目标：明确优化方向（如“将耗时降至 3 秒内”“避免全表扫描”）。

（三）实战案例：优化电商订单查询 SQL

1. 原始 SQL 与性能问题

原始需求：查询 2024 年 5 月北京地区用户的订单，显示订单 ID、用户 ID、订单金额、下单时间，按下单时间降序排列。
原始 SQL：

SELECT order_id,user_id,order_amount,create_timeFROM `order`WHERE DATE(create_time) = '2024-05-01' AND user_address LIKE '%北京%'ORDER BY create_time DESC;

性能现状：

• 数据库：MySQL 8.0；
• 表数据量：order 表 800 万行，无索引（除 order_id 主键）；
• 执行耗时：22 秒；
• 执行计划：type: ALL（全表扫描）、Extra: Using where; Using filesort（文件排序）。

2. 优化 Prompt 设计

请作为 MySQL 性能优化工程师，基于以下信息优化 SQL 语句：
1. 原始 SQL：
   [此处粘贴上述原始 SQL]
2. 数据库环境：
   - 数据库类型：MySQL 8.0
   - 表信息：`order` 表 800 万行，字段类型：
     order_id（INT，主键，自增）、user_id（INT）、order_amount（DECIMAL(10,2)）、create_time（DATETIME）、user_address（VARCHAR(255)）
   - 索引情况：仅 order_id 为主键索引，无其他二级索引
3. 性能问题：
   - 执行耗时 22 秒，存在全表扫描（type: ALL）；
   - 执行计划显示 "Using where; Using filesort"，文件排序耗时严重。
4. 优化要求：
   - 避免全表扫描，减少执行时间至 3 秒内；
   - 不修改业务逻辑（结果与原始 SQL 一致）；
   - 提供优化后的 SQL 语句，并详细说明优化点（含索引建议、语法调整理由）。

3. 优化后的 SQL 与分析

（1）优化后的 SQL

-- 1. 创建联合索引（覆盖查询+筛选+排序）CREATE INDEX idx_order_createaddr ON `order` (create_time, user_address) INCLUDE (order_id, user_id, order_amount);-- 2. 优化后的查询 SQLSELECT order_id,user_id,order_amount,create_timeFROM `order`WHERE create_time BETWEEN '2024-05-01 00:00:00' AND '2024-05-01 23:59:59'-- 替换 DATE() 函数，利用索引AND user_address LIKE '北京%'-- 优化 LIKE 条件，避免 % 开头（索引有效）ORDER BY create_time DESC;

（2）优化点详细说明

（3）优化后性能预期

• 执行耗时：1.2 秒（从 22 秒降至 3 秒内）；
• 执行计划：type: range（范围扫描，非全表）、Extra: Using index（使用覆盖索引，无回表），无“Using filesort”。

五、Prompt 驱动 SQL 生成与优化的进阶技巧

（一）动态 SQL 生成：用占位符适配变量需求

在实际场景中，SQL 的筛选条件可能是动态的（如按用户输入的日期范围查询）。此时，可在 Prompt 中使用占位符（如 {start_date}、{end_date}），让 LLM 生成可复用的动态 SQL 模板。

示例 Prompt：

请生成动态 SQL 模板（适用于 Python 后端调用），需求如下：
1. 表名：sales_order
2. 需求：按动态日期范围（{start_date} 至 {end_date}）和订单状态（{order_status}，可选值：1=待付款，2=已付款，3=已取消）查询订单，显示订单 ID、用户 ID、订单金额。
3. 输出要求：
   - 使用占位符 {start_date}、{end_date}、{order_status} 表示动态变量；
   - 生成 Python 中使用 SQLAlchemy 执行的参数化查询代码（避免 SQL 注入）；
   - 包含参数校验逻辑（如 {start_date} 需小于 {end_date}）。

预期输出：

from sqlalchemy import create_engine, textfrom datetime import datetimedef query_orders_by_date(engine, start_date: str, end_date: str, order_status: int):# 1. 参数校验try:start_dt = datetime.strptime(start_date, "%Y-%m-%d")end_dt = datetime.strptime(end_date, "%Y-%m-%d")if start_dt > end_dt:raise ValueError("开始日期不能晚于结束日期")if order_status not in [1, 2, 3]:raise ValueError("订单状态仅支持 1（待付款）、2（已付款）、3（已取消）")except ValueError as e:raise e# 2. 动态 SQL 模板（参数化查询，避免 SQL 注入）sql_template = text("""SELECT order_id,user_id,order_amountFROM sales_orderWHERE create_time BETWEEN :start_date AND :end_dateAND order_status = :order_statusORDER BY create_time DESC;""")# 3. 执行查询（使用参数绑定）with engine.connect() as conn:result = conn.execute(sql_template,{"start_date": start_date, "end_date": end_date, "order_status": order_status})return [dict(row) for row in result]

（二）多数据库兼容：在 Prompt 中指定语法差异

不同数据库的 SQL 语法存在差异（如日期函数、分页方式），可在 Prompt 中明确“数据库差异点”，让 LLM 生成兼容多数据库的 SQL。

示例 Prompt 片段：

请生成兼容 MySQL 8.0 和 PostgreSQL 14 的 SQL 语句，需注意以下语法差异：
1. 分页方式：MySQL 用 LIMIT，PostgreSQL 用 FETCH FIRST N ROWS ONLY；
2. 日期函数：MySQL 用 DATE_FORMAT(create_time, '%Y-%m-%d')，PostgreSQL 用 TO_CHAR(create_time, 'YYYY-MM-DD')；
3. 字符串拼接：MySQL 用 CONCAT(a, b)，PostgreSQL 用 a || b。
需求：查询近 7 天的订单数，按日期分组，显示日期（YYYY-MM-DD）和订单数，取前 5 天数据。

（三）结合执行计划：让 Prompt 更精准

执行计划是 SQL 优化的核心依据（如 EXPLAIN ANALYZE 输出）。在 Prompt 中提供执行计划信息，可让 LLM 直接定位性能瓶颈（如全表扫描、索引失效），避免盲目优化。

示例 Prompt 片段：

请基于以下执行计划优化 SQL：
1. 执行计划（MySQL 8.0，EXPLAIN ANALYZE 输出）：
   id | select_type | table | type | possible_keys | key| key_len | ref| rows| filtered | Extra
   ----|-------------|-------|------|---------------|------|---------|------|-------|----------|--------------------------
   1| SIMPLE| order | ALL| NULL| NULL | NULL| NULL | 8000000 | 10.00| Using where; Using filesort
2. 原始 SQL：[此处粘贴 SQL]
3. 优化要求：消除全表扫描和文件排序，执行时间降至 5 秒内。

六、常见问题与解决方案

（一）LLM 生成的 SQL 语法错误

问题表现：生成的 SQL 包含语法错误（如字段名错误、缺少逗号、子查询位置不当）。
解决方案：

• 在 Prompt 中“逐字段”列出表结构（含表名、字段名、数据类型），避免 LLM 猜测；
• 增加“语法校验要求”（如“生成后请自行检查语法，确保无缺少逗号、括号匹配等错误”）；
• 提供 1 个正确的 SQL 示例（Few-Shot），让 LLM 学习语法规范。

（二）SQL 符合语法但不符合业务逻辑

问题表现：SQL 可执行，但结果与业务需求不符（如统计“订单金额”时用了 COUNT 而非 SUM）。
解决方案：

• 在 Prompt 中明确“业务术语定义”（如“订单金额总和指所有有效订单的 order_amount 字段求和”）；
• 增加“结果验证逻辑”（如“生成的 SQL 需确保：当订单状态为 3（已取消）时，不纳入统计”）；
• 提供“预期结果示例”（如“若 2024-05-01 北京地区有 10 笔有效订单，金额总和 20000 元，则 SQL 应返回 20000”）。

（三）优化建议不落地（如要求创建过多索引）

问题表现：LLM 建议创建大量索引，但实际场景中索引会增加写入开销（如插入/更新变慢）。
解决方案：

• 在 Prompt 中补充“业务场景约束”（如“该表日均插入 10 万条数据，需平衡查询与写入性能，索引数量不超过 3 个”）；
• 要求 LLM 提供“索引取舍理由”（如“建议创建联合索引而非单字段索引，理由：可同时覆盖筛选、排序、查询字段，减少索引数量”）；
• 明确“优化优先级”（如“优先通过语法优化（如调整 WHERE 条件）提升性能，其次考虑索引”）。

七、本章总结与实践建议

本章系统讲解了 Prompt 驱动的 SQL 生成与查询优化方法，核心结论如下：

• Prompt 设计三要素：明确表结构（字段名、数据类型）、细化业务逻辑（筛选条件、统计规则）、指定技术约束（数据库类型、语法规范），是生成精准 SQL 的基础；
• 优化思路四步走：先通过执行计划定位瓶颈（如全表扫描、文件排序），再针对性优化（索引设计、语法调整、逻辑重构），最后验证性能效果；
• 进阶技巧核心：利用占位符实现动态 SQL、结合执行计划提升优化精准度、考虑多数据库兼容与业务约束，可让 Prompt 适配更复杂场景。

实践建议：

• 新手入门：从单表查询开始，逐步尝试多表关联，每生成一个 SQL 后，先在测试环境执行验证结果，再应用到生产；
• 工程师提升：学习解读执行计划（如 EXPLAIN 输出），将执行计划信息融入 Prompt，让 LLM 提供更落地的优化建议；
• 团队协作：建立“Prompt 模板库”，按业务场景（如电商订单查询、金融风控统计）分类存储优质 Prompt，提升团队效率。

通过本章内容的实践，读者可显著降低 SQL 编写与优化的门槛，实现“用自然语言快速生成高效 SQL”，让数据需求响应更高效、数据库性能更稳定。