LLM生成SQL：规则与示例引导策略的实战对比与最佳实践

在数据库开发与数据分析的日常工作中，编写正确、高效的 SQL 语句是一项核心技能。随着大语言模型（LLM）在代码生成领域的广泛应用，越来越多的开发者开始尝试使用 LLM 来辅助编写 SQL。然而，一个常见且令人困惑的问题是：当我们向 LLM 提问时，究竟是提供详细的语法规则（Rules）更有效，还是直接给出几个具体的查询示例（Examples）更能帮助它生成正确的 SQL？本文将深入探讨这一话题，通过对比实验、原理分析和实战演示，为你揭示在不同场景下，如何更有效地引导 LLM 成为你的 SQL 编写助手。

1. 背景与核心概念：LLM 如何“理解”SQL

在深入探讨“规则”与“示例”之前，我们首先需要理解 LLM 处理 SQL 的基本原理。LLM 并非一个理解数据库原理的程序，而是一个基于海量文本数据训练出的概率模型。它通过学习代码库、技术文档、问答社区（如 Stack Overflow）中的模式，来预测给定上下文后最可能出现的下一个词或代码片段。

1.1 LLM 的 SQL 知识来源LLM 关于 SQL 的知识主要来自训练数据中的以下内容：

• 教科书与官方文档：提供了标准的语法规则和定义。
• 开源代码库：包含了大量实际项目中的 SQL 语句，展现了各种复杂查询、优化技巧和特定数据库方言的用法。
• 技术问答与博客：提供了大量“问题-解决方案”对，例如“如何实现行转列”、“如何优化慢查询”。

因此，LLM 的“知识”是规则（从文档中学到的范式）和示例（从代码和问答中学到的具体实例）的混合体。当我们提问时，我们实际上是在激活和引导模型内部这些已有的模式。

1.2 “规则”与“示例”的定义

• 规则（Rules）：指对 SQL 语法、语义、约束的抽象描述。例如：“JOIN子句用于连接两个表，需要指定连接条件ON。”，“GROUP BY后面跟的字段，SELECT子句中非聚合字段必须出现在其中。”
• 示例（Examples）：指一个或多个完整、可运行的 SQL 语句及其对应的上下文（如表结构、查询目标）。例如，给出一个users表和一个orders表，然后展示一个连接它们并计算每个用户订单总数的查询。

这两种方式对应了人类学习的两种途径：通过理解抽象原理来推导，以及通过模仿具体案例来掌握。接下来，我们将通过实战来检验哪种方式对 LLM 更有效。

2. 环境准备与实验设计

为了进行公平的对比，我们需要一个统一的测试环境。本文将以 OpenAI 的 GPT-4 模型为例进行演示，但结论和方法论适用于多数主流 LLM（如 Claude、DeepSeek Coder 等）。

2.1 基础环境

• LLM 接口：OpenAI API (GPT-4) 或 ChatGPT 界面。
• 测试数据库：我们虚构一个简单的电商数据库用于所有测试，确保问题背景一致。
• 表结构如下：

-- 用户表 CREATE TABLE users ( user_id INT PRIMARY KEY, username VARCHAR(50), country VARCHAR(50) ); -- 订单表 CREATE TABLE orders ( order_id INT PRIMARY KEY, user_id INT, product_name VARCHAR(100), amount DECIMAL(10, 2), order_date DATE, FOREIGN KEY (user_id) REFERENCES users(user_id) ); -- 插入示例数据（用于让LLM理解数据关系） INSERT INTO users VALUES (1, 'Alice', 'USA'), (2, 'Bob', 'UK'), (3, 'Charlie', 'USA'); INSERT INTO orders VALUES (101, 1, 'Laptop', 1200.00, '2023-10-01'), (102, 1, 'Mouse', 25.50, '2023-10-02'), (103, 2, 'Keyboard', 80.00, '2023-10-01');

2.2 实验方法我们将设计一系列复杂度递增的 SQL 问题，并分别用三种不同的方式向 LLM 提问：

1. 仅提供规则：用文字描述查询需求，并可能附加语法规则提示。
2. 仅提供示例：不解释规则，直接给出一个或多个类似但不同的查询示例。
3. 混合模式：结合规则和示例。

我们将从语法正确性、语义准确性（是否完全满足需求）、代码质量（是否高效、规范）三个维度评估生成的 SQL。

3. 实战对比：规则 vs. 示例

3.1 场景一：基础查询与过滤（简单）

任务：查询来自 ‘USA’ 的所有用户及其订单信息。

方式A：仅提供规则

提示词：请编写一条 SQL 查询。我们需要从users表和orders表进行连接。连接条件是users.user_id = orders.user_id。我们只需要来自 ‘USA’ 的用户。请使用INNER JOIN并正确使用ON子句。最后，按order_date降序排列。

LLM 生成结果：

SELECT u.user_id, u.username, o.order_id, o.product_name, o.amount, o.order_date FROM users u INNER JOIN orders o ON u.user_id = o.user_id WHERE u.country = 'USA' ORDER BY o.order_date DESC;

评价：语法完全正确，语义准确。模型严格遵循了提示中的每一条规则。

方式B：仅提供示例

提示词：参考以下查询示例，它查询了来自 ‘UK’ 的用户订单：

SELECT u.username, o.product_name FROM users u JOIN orders o ON u.user_id = o.user_id WHERE u.country = 'UK';

现在，请写一个查询，获取来自 ‘USA’ 的用户的所有订单详情。

LLM 生成结果：

SELECT u.user_id, u.username, o.order_id, o.product_name, o.amount, o.order_date FROM users u JOIN orders o ON u.user_id = o.user_id WHERE u.country = 'USA';

评价：语法正确，语义准确。模型成功地从示例中提取了模式（JOIN...ON...WHERE country=），并替换了条件值。但可能缺少ORDER BY，因为示例中没有。

小结：对于简单、模式清晰的任务，规则和示例都能很好地工作。规则能确保所有细节被覆盖（如排序），而示例则更简洁，但可能遗漏规则中未体现的次要需求。

3.2 场景二：分组聚合与过滤（中等难度）

任务：统计每个国家的用户订单总金额，并且只显示总金额大于 1000 的国家。

方式A：仅提供规则

提示词：需要按users.country分组，对orders.amount求和。然后，使用HAVING子句过滤出总和大于 1000 的分组。记住，WHERE用于过滤行，HAVING用于过滤分组。SELECT列表中要包含分组字段和聚合结果。

LLM 生成结果：

SELECT u.country, SUM(o.amount) as total_amount FROM users u INNER JOIN orders o ON u.user_id = o.user_id GROUP BY u.country HAVING SUM(o.amount) > 1000;

评价：完美。模型正确应用了GROUP BY、SUM和HAVING。

方式B：仅提供示例

提示词：以下是一个按产品统计订单数量的例子：

SELECT product_name, COUNT(*) as order_count FROM orders GROUP BY product_name HAVING COUNT(*) > 1;

请根据这个模式，写一个查询：按国家统计订单总金额，并筛选出总金额大于1000的国家。

LLM 生成结果：

SELECT u.country, SUM(o.amount) as total_amount FROM users u JOIN orders o ON u.user_id = o.user_id GROUP BY u.country HAVING SUM(o.amount) > 1000;

评价：同样完美。模型准确地将示例中的模式（GROUP BY字段，聚合函数COUNT，HAVING过滤聚合结果）迁移到了新任务上，将product_name替换为u.country，COUNT(*)替换为SUM(o.amount)。

小结：对于具有标准模式的中等难度任务（如聚合+过滤），示例的迁移效果非常好，甚至比冗长的规则描述更高效。LLM 非常擅长这种“类比”学习。

3.3 场景三：复杂子查询与窗口函数（高难度）

任务：找出每个国家消费金额最高的用户（并列第一则都显示）。

方式A：仅提供规则

提示词：这是一个复杂查询。首先，你需要为每个用户计算其总消费金额。然后，在每一个国家内部，你需要找到消费金额最高的用户。这需要使用到子查询和窗口函数。建议步骤：1. 创建一个子查询或CTE，计算每个用户的所属国家和总金额。2. 使用窗口函数RANK() OVER (PARTITION BY country ORDER BY total_amount DESC)为每个国家的用户排名。3. 在最外层选择排名为1的记录。注意处理并列情况。

LLM 生成结果：

WITH user_total AS ( SELECT u.user_id, u.username, u.country, SUM(o.amount) as total_amount FROM users u JOIN orders o ON u.user_id = o.user_id GROUP BY u.user_id, u.username, u.country ) SELECT user_id, username, country, total_amount FROM ( SELECT *, RANK() OVER (PARTITION BY country ORDER BY total_amount DESC) as rank_in_country FROM user_total ) ranked WHERE rank_in_country = 1;

评价：优秀。模型严格遵循了规则描述的步骤，生成了结构清晰、正确的 SQL，使用了 CTE（公用表表达式）和RANK()窗口函数。

方式B：仅提供示例

提示词：这里有一个例子，它找出了每个产品类别中销售额最高的订单（使用DENSE_RANK）：

WITH order_sales AS ( SELECT category, order_id, sales, DENSE_RANK() OVER (PARTITION BY category ORDER BY sales DESC) as sales_rank FROM sales_records ) SELECT category, order_id, sales FROM order_sales WHERE sales_rank = 1;

请模仿这个结构，写一个查询：找出每个国家消费总额最高的用户。

LLM 生成结果：

WITH user_spending AS ( SELECT u.country, u.user_id, u.username, SUM(o.amount) as total_spent FROM users u JOIN orders o ON u.user_id = o.user_id GROUP BY u.country, u.user_id, u.username ) SELECT country, user_id, username, total_spent FROM ( SELECT *, DENSE_RANK() OVER (PARTITION BY country ORDER BY total_spent DESC) as spending_rank FROM user_spending ) ranked_users WHERE spending_rank = 1;

评价：同样优秀。模型成功地将示例中的“类别-产品-销售额”模式迁移到了“国家-用户-消费总额”上，并且正确选择了DENSE_RANK来处理并列（根据示例），或者也可能生成RANK()。

小结：对于复杂查询，详细的规则能确保 LLM 遵循特定的解决路径（如使用RANK而非ROW_NUMBER），适合有严格实现要求的场景。而高质量的示例则能提供更直观、可复用的结构模板，迁移效率极高。两者在此场景下打成平手。

4. 深入分析：何时用规则？何时用示例？

通过以上实验，我们可以总结出一些指导原则：

4.1 优先使用“示例”的场景

• 模式迁移：当新任务与一个已知示例在结构上高度相似，只是表名、字段名、条件值不同时。LLM 非常擅长这种“填空”式生成。
• 语法复杂但结构固定：如窗口函数、CTE、复杂CASE WHEN语句。一个正确的示例比一页语法描述更管用。
• 快速原型构建：当你需要快速得到一个可运行的查询草稿时，提供一个类似示例是最快的方式。
• 学习特定风格：如果你想生成的 SQL 符合某种特定风格（如使用特定的别名约定、缩进格式），提供该风格的示例是最佳途径。

4.2 优先使用“规则”的场景

• 约束与边界条件：当需求中包含容易被忽略的细节时，必须用规则明确说明。例如，“结果必须去重（DISTINCT）”、“需要处理NULL值”、“必须使用左连接以包含没有订单的用户”。
• 纠正错误模式：如果发现 LLM 反复犯某种错误（例如，在GROUP BY后错误地选择非聚合字段），直接提供明确的规则进行纠正比提供另一个示例更有效。
• 安全性要求：需要强调安全规则，例如“禁止使用字符串拼接生成查询，必须使用参数化查询”，这必须作为规则明确提出。
• 性能优化提示：例如“在status字段上添加索引以提高此查询性能”，这类元建议更适合以规则形式给出。

4.3 最佳实践：混合策略（规则 + 示例）在实际使用中，最有效的方法往往是混合策略：提供一个清晰的示例作为主体框架，同时用简短的规则点明关键约束和易错点。

混合提示词示例： 我需要查询每个部门薪资最高的员工（允许并列）。请参考以下结构示例，它查询了每个班级分数最高的学生：

WITH student_scores AS (...), ranked AS (SELECT *, DENSE_RANK() OVER (PARTITION BY class_id ORDER BY score DESC) as rank ...) SELECT ... FROM ranked WHERE rank = 1;

请注意以下几点规则：

1. 我们有两张表：employees (id, name, dept_id, salary)和departments (id, dept_name)。
2. 使用DENSE_RANK()以确保并列第一的员工都能被选出。
3. 结果中需要包含部门名称和员工姓名。

这种结合方式既给了模型一个强大的模板，又用规则锁定了关键需求，能极大提高生成 SQL 的准确率和可靠性。

5. 常见问题与排查思路

在使用 LLM 生成 SQL 时，即使采用了最佳策略，也可能遇到问题。以下是一些常见问题及解决方法。

6. 最佳实践与工程建议

要将 LLM 高效、安全地集成到你的 SQL 开发工作流中，请遵循以下工程实践：

6.1 提示词工程标准化

• 提供精确的上下文：始终在提示词开头提供清晰、完整的表结构定义。这是生成正确 JOIN 和 WHERE 子句的基础。
• 分而治之：对于极其复杂的查询，不要指望一个提示词就能解决。将其分解为多个子任务（例如，先让 LLM 设计中间表结构，再编写最终查询）。
• 指定输出格式：明确要求“请只输出 SQL 代码，不要有任何解释”，以避免模型输出冗余文本。

6.2 安全与验证

• 绝不直接在生产环境运行：始终在开发或测试环境中验证 LLM 生成的 SQL。
• 防范 SQL 注入：LLM 生成的动态 SQL 如果涉及拼接，风险极高。必须强制使用参数化查询（Prepared Statements），并将此作为核心规则写入提示词。
• 权限最小化：用于执行 LLM 生成 SQL 的数据库账号，应仅具有查询必要数据的最小权限，禁止使用高权限账号。

6.3 迭代与优化

• 利用交互：如果第一次生成不理想，不要放弃。将错误信息或不符合预期的结果反馈给模型，让它进行修正。LLM 在迭代中通常能表现得更好。
• 构建个人或团队的示例库：将经过验证的、高质量的提示词（特别是混合了规则和示例的）保存下来，形成可复用的知识库，能极大提升团队效率。
• 结合专业工具：将 LLM 视为强大的“副驾驶”，而非完全自动驾驶。生成的 SQL 应结合数据库客户端工具、性能分析工具（如EXPLAIN）和代码审查流程一起使用。

6.4 针对不同数据库的适配

• 明确声明方言：在提示词中明确指出是 MySQL、PostgreSQL、Oracle、SQL Server 还是 BigQuery。它们的函数（如日期处理、字符串处理）、语法（如分页查询LIMITvsTOPvsROWNUM）常有差异。
• 提供方言特定示例：如果你经常使用某个数据库，为其收集和制作特定的示例集，效果会远好于通用示例。

通过理解 LLM 的工作原理，并策略性地运用“规则”与“示例”，你可以将其转化为一个强大的 SQL 编写助手。记住，没有放之四海而皆准的方法：对于简单的模式匹配，示例是捷径；对于精确的约束和控制，规则不可替代；而对于大多数现实世界的复杂任务，将两者结合的混合策略才是王道。从今天起，在你的下一个数据查询任务中，有意识地设计你的提示词，观察并优化你与 LLM 的协作方式，你会发现编写正确、高效的 SQL 不再是一件令人头疼的苦差事。