← Retour aux guides

用 LLM 生成 SQL 的 7 个实战技巧：从需求到可执行查询

1. 先提供表结构，别只问“帮我写 SQL”

LLM 不知道你的字段含义、主外键关系和枚举值。把相关表的表名、字段名、类型、注释，以及关键关联关系一起输入，生成质量会明显提升。例如明确说明 users.id 关联 orders.user_id、orders.status 只有 paid 和 refunded，模型才能正确写出统计付费订单的查询。

2. 在提示词里锁定数据库方言

MySQL、PostgreSQL、BigQuery、ClickHouse 和 SQL Server 的日期函数、分页语法、JSON 函数并不相同。请求中应直接写明“仅输出 PostgreSQL 15 可执行 SQL”，并指定时区、字符集和日期范围。需要兼容 ORM 时，也要说明参数占位格式，例如 PostgreSQL 使用 $1，Python DB-API 常用 %(start_date)s。

3. 用业务问题描述指标口径

“本月活跃用户”可能是登录用户、下单用户，或访问过页面的用户。不要把指标定义留给模型猜测。应写清去重字段、过滤条件和时间边界，例如：按北京时间统计自然月内至少支付一笔订单的 distinct user_id，不包含测试账号和退款订单。口径明确后，LLM 生成的 GROUP BY 与 WHERE 条件才可复用。

4. 要求模型先解释，再输出最终查询

对于复杂查询，可要求模型先列出涉及表、连接条件、过滤规则和聚合逻辑，再给出 SQL。这个过程能快速发现“订单金额是否含税”“LEFT JOIN 是否会丢失无订单用户”之类的问题。上线执行时，仍应让接口最终返回纯 SQL，方便程序提取、参数化和执行。

5. 把安全规则写成不可违反的约束

• 只允许 SELECT、WITH 和 EXPLAIN，禁止 INSERT、UPDATE、DELETE、DROP、ALTER。
• 默认附加 LIMIT，明细查询限制返回行数。
• 敏感字段如手机号、邮箱、身份证只能聚合或脱敏输出。
• 所有外部输入使用绑定参数，不能把用户文本直接拼进 SQL。

LLM 输出不是安全边界。应用侧还应使用 SQL 解析器或只读数据库账号二次校验，并在生产库执行前先跑 EXPLAIN。

6. 建立“生成、验证、修正”的查询循环

一次生成不一定正确。将数据库返回的报错、空结果数量、EXPLAIN 成本和少量样例结果反馈给模型，要求它只修正问题部分。例如出现 column does not exist 时，同时提供真实字段名；扫描行数过大时，要求改用索引字段、预聚合表或更窄的时间范围。把成功查询保存为 few-shot 示例，后续同类报表会更稳定。

7. 用低成本 API 把能力接入现有工具链

批量生成查询、做 SQL 审查和解释报表逻辑都会消耗模型调用额度。59API 提供按量付费的 Claude 与 GPT 模型访问，兼容 Claude Code、Codex 和 OpenAI SDK，API Base URL 为 https://api.59api.com。其原生官方质量模型覆盖 Claude Opus、Sonnet、Haiku、Fable 及 GPT 系列，适合按任务复杂度选择模型：简单字段映射使用更快的模型，跨表分析和查询优化再使用更强模型。

在代码中保留现有 OpenAI SDK 调用方式，只需将 base_url 指向 59API，并通过环境变量管理密钥即可开始测试。先用脱敏 schema 和只读测试库验证提示词效果，再逐步接入生产报表流程。需要控制 LLM 数据查询成本的团队，可以注册 59API 试用其按量计费与推荐返利方案。

Tarifs · Docs