AI的提示词专栏：Prompt 驱动的 SQL 生成与查询优化-sql-CSS教程网

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

本文聚焦 Prompt 技术在 SQL 领域的应用，先剖析 SQL 生成与优化的痛点，阐述 Prompt 驱动 SQL 生成的核心原理，即通过需求转化、约束注入和示例引导实现自然语言到 SQL 的精准映射。随后结合电商、金融、互联网产品等场景，提供基础型、进阶型、复杂型三类 Prompt 实战案例，展示不同需求下的 Prompt 设计与 SQL 生成过程。还讲解了 Prompt 驱动 SQL 查询优化的方法，包括识别性能瓶颈、设计优化 Prompt 及实战案例分析，同时给出动态 SQL 生成、多数据库兼容等进阶技巧，解答常见问题并提供实践建议，助力读者降低 SQL 编写与优化门槛，提升数据需求响应效率与数据库性能。

人工智能专栏介绍

人工智能学习合集专栏是 AI 学习者的实用工具。它像一个全面的 AI 知识库，把提示词设计、AI 创作、智能绘图等多个细分领域的知识整合起来。无论你是刚接触 AI 的新手，还是有一定基础想提升的人，都能在这里找到合适的内容。从最基础的工具操作方法，到背后深层的技术原理，专栏都有讲解，还搭配了实例教程和实战案例。这些内容能帮助学习者一步步搭建完整的 AI 知识体系，让大家快速从入门进步到精通，更好地应对学习和工作中遇到的 AI 相关问题。

这个系列专栏能教会人们很多实用的 AI 技能。在提示词方面，能让人学会设计精准的提示词，用不同行业的模板高效和 AI 沟通。写作上，掌握从选题到成稿的全流程技巧，用 AI 辅助写出高质量文本。编程时，借助 AI 完成代码编写、调试等工作，提升开发速度。绘图领域，学会用 AI 生成符合需求的设计图和图表。此外，还能了解主流 AI 工具的用法，学会搭建简单智能体，掌握大模型的部署和应用开发等技能，覆盖多个场景，满足不同学习者的需求。

1️⃣ ⚡ 点击进入 AI 的提示词专栏，专栏拆解提示词底层逻辑，从明确指令到场景化描述，教你精准传递需求。还附带包含各行业适配模板：医疗问诊话术、电商文案指令等，附优化技巧，让 AI 输出更贴合预期，提升工作效率。

2️⃣ ⚡ 点击进入 AI 灵感写作专栏，AI 灵感写作专栏，从选题到成稿，全流程解析 AI 写作技巧。涵盖论文框架搭建、小说情节生成等，教你用提示词引导 AI 输出内容，再进行人工润色。附不同文体案例，助你解决写作卡壳，产出高质量文本。

3️⃣ ⚡ 点击进入 AI 辅助编程专栏，AI 辅助编程专栏，通过实例教你用 AI 写代码：从功能描述到调试优化。涵盖前端、后端、数据库等，语言包括HTML5、VUE、Python、Java、C# 等语言，含算法实现、Bug 修复技巧，帮开发者减少重复劳动，专注核心逻辑，提升开发速度。

4️⃣ ⚡ 点击进入 AI 精准绘图专栏，AI 精准绘图，聚焦 AI 绘图在设计场景的落地。详解如何描述风格、元素、用途，生成 logo、商标等。含 Midjourney 等工具参数设置，及修改迭代方法，帮设计新手快速出图，满足商业与个人需求。

5️⃣ ⚡ 点击进入 AI 绘制图表专栏，AI 绘制图表专栏，教你用 AI 工具将数据转化为直观图表。涵盖曲线图数据输入、流程图逻辑梳理等，附 Excel 联动、格式美化技巧，适合学生、职场人快速制作专业图表，提升数据展示效果。

6️⃣ ⚡ 点击进入 AI 的工具集专栏，AI 的工具集专栏，盘点主流 AI 工具：ChatGPT、DeepSeek、 Claude、Gemini、Copilot 等。解析各工具优势，附使用场景与技巧，帮你根据需求选工具，快速上手提升效率，覆盖办公、创作、开发等场景。

7️⃣ ⚡ 点击进入 AI 的智能体专栏，AI 的智能体专栏，解析智能体自主运行原理，包括任务拆解、环境交互等。教你用大模型搭建简单智能体，附多智能体协作案例，适合想探索 AI 自主系统的开发者入门。

8️⃣ ⚡ 点击进入 AI 的大模型专栏，AI 的大模型专栏，详解大模型部署步骤，从本地搭建到云端部署。含 API 调用教程、应用开发案例，教你将大模型集成到项目，掌握企业级 AI 应用开发技能，应对实际业务需求。

一、引言：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）与统计函数（AVG），避免语法错误。

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

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

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

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

案例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_quantity
FROM 
    sales_product
WHERE 
    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 li
INNER 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  -- 按用户分组（需包含非聚合字段）
HAVING 
    SUM(li.overdue_amount) > 0;  -- 过滤逾期金额大于 0 的用户

技巧点分析：

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

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

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

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

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

精准 Prompt 设计：

请生成兼容 SQL Server 的 SQL 语句，用于用户行为漏斗分析，具体要求如下：
1. 数据库表结构：
   - 表名：user_behavior
   - 字段：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_behavior AS (
    -- CTE：按日期和行为类型统计独立用户数
    SELECT 
        CONVERT(VARCHAR(10), event_time, 23) AS date,  -- 格式化日期为 YYYY-MM-DD
        event_type,
        COUNT(DISTINCT user_id) AS user_count  -- 独立用户数（去重）
    FROM 
        user_behavior
    WHERE 
        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_rate
FROM 
    daily_behavior
GROUP BY 
    date
ORDER BY 
    date;

技巧点分析：

CTE 简化逻辑：通过 daily_behavior 公共表表达式先统计“日期+行为类型”的用户数，避免后续重复写 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_time
FROM 
    `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. 优化后的查询 SQL
SELECT 
    order_id,
    user_id,
    order_amount,
    create_time
FROM 
    `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）优化点详细说明

优化方向	原始问题	优化措施	原理
索引优化	仅主键索引，全表扫描	创建联合索引 `idx_order_createaddr`（`create_time`, `user_address`），并通过 `INCLUDE` 包含查询字段	1. `create_time` 作为索引首列，可快速筛选 5 月 1 日的数据，避免全表扫描； 2. `user_address` 作为第二列，进一步筛选北京地区数据； 3. `INCLUDE` 包含 `order_id` 等查询字段，实现“覆盖索引”（无需回表查询数据，直接从索引获取结果）
语法优化	`DATE(create_time) = '2024-05-01'` 导致索引失效	替换为 `create_time BETWEEN '2024-05-01 00:00:00' AND '2024-05-01 23:59:59'`	函数操作索引字段（如 `DATE(create_time)`）会破坏索引有序性，导致索引失效；直接比较字段值可正常使用索引
条件优化	`user_address LIKE '%北京%'` 导致索引失效	调整为 `user_address LIKE '北京%'`（假设地址格式为“北京朝阳区…”）	`LIKE '%xxx'` 或 `LIKE '%xxx%'` 会导致索引失效（无法按前缀匹配）；`LIKE 'xxx%'` 可利用索引的前缀匹配特性，提升筛选效率
排序优化	`ORDER BY create_time DESC` 触发文件排序	利用索引的有序性（`create_time` 为索引列）	索引本身按 `create_time` 有序排列，查询时可直接按索引顺序返回结果，避免额外的“文件排序”操作

（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, text
from datetime import datetime

def 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_amount
        FROM 
            sales_order
        WHERE 
            create_time BETWEEN :start_date AND :end_date
            AND order_status = :order_status
        ORDER 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”，让数据需求响应更高效、数据库性能更稳定。

联系博主

xcLeigh 博主，全栈领域优质创作者，博客专家，目前，活跃在CSDN、微信公众号、小红书、知乎、掘金、快手、思否、微博、51CTO、B站、腾讯云开发者社区、阿里云开发者社区等平台，全网拥有几十万的粉丝，全网统一IP为 xcLeigh。希望通过我的分享，让大家能在喜悦的情况下收获到有用的知识。主要分享编程、开发工具、算法、技术学习心得等内容。很多读者评价他的文章简洁易懂，尤其对于一些复杂的技术话题，他能通过通俗的语言来解释，帮助初学者更好地理解。博客通常也会涉及一些实践经验，项目分享以及解决实际开发中遇到的问题。如果你是开发领域的初学者，或者在学习一些新的编程语言或框架，关注他的文章对你有很大帮助。

亲爱的朋友，无论前路如何漫长与崎岖，都请怀揣梦想的火种，因为在生活的广袤星空中，总有一颗属于你的璀璨星辰在熠熠生辉，静候你抵达。

愿你在这纷繁世间，能时常收获微小而确定的幸福，如春日微风轻拂面庞，所有的疲惫与烦恼都能被温柔以待，内心永远充盈着安宁与慰藉。

至此，文章已至尾声，而您的故事仍在续写，不知您对文中所叙有何独特见解？期待您在心中与我对话，开启思想的新交流。

💞 关注博主 🌀 带你实现畅游前后端！

🏰 大屏可视化 🌀 带你体验酷炫大屏！

💯 神秘个人简介 🌀 带你体验不一样得介绍！

🥇 从零到一学习Python 🌀 带你玩转Python技术流！

🏆 前沿应用深度测评 🌀 前沿AI产品热门应用在线等你来发掘！

💦 注：本文撰写于CSDN平台,作者：xcLeigh（所有权归作者所有） ，https://xcleigh.blog.csdn.***/，如果相关下载没有跳转，请查看这个地址，相关链接没有跳转，皆是抄袭本文，转载请备注本文原地址。

📣 亲，码字不易，动动小手，欢迎 点赞 ➕ 收藏，如 🈶 问题请留言（或者关注下方公众号，看见后第一时间回复，还有海量编程资料等你来领！），博主看见后一定及时给您答复 💌💌💌

转载请说明出处内容投诉
CSS教程网 » AI的提示词专栏：Prompt 驱动的 SQL 生成与查询优化

谢生

分享到：