核心要点
基本流程：把库表 schema + 用户问题给模型 → 生成 SQL → 执行 → 返回结果（可再让模型用自然语言解释）
安全是第一位：用只读账号、限制可访问的表、SQL 执行前做语法/权限校验，防止注入和误删
提供 schema 和字段语义说明、few-shot 示例，模型才知道表结构和业务含义，否则瞎编字段名
执行报错要自动重试：把数据库错误信息回喂给模型让它修正 SQL，复杂查询易错需人工确认
标准回答
核心链路
Text-to-SQL 就是「schema + 问题 → SQL → 执行 → 结果」。给模型喂相关表的建表语句、字段注释、少量查询示例，再加用户的自然语言问题，让它生成 SQL。生成后在数据库执行，拿到结果返回，可选地再让模型把结果翻译成人话。
安全必须卡死
这是最容易出事的地方：
- 只读权限：连接用单独的只读账号，从根上杜绝 UPDATE/DELETE/DROP。
- 白名单：限制能访问的库和表，敏感表（用户隐私）不暴露。
- SQL 校验：执行前解析 SQL，拦截非 SELECT 语句、危险关键字。
- 加 LIMIT、超时、行数上限，防止大查询拖垮库。
提准确率
模型不懂业务字段含义会瞎编。要把 schema、字段注释、枚举值、典型 query 示例（few-shot）放进 prompt。表多就先做一步「相关表召回」只给相关 schema，别把整库塞进去。
错误重试
SQL 执行报错时，把错误信息回喂给模型让它自我修正，重试 1-2 次。复杂多表关联容易错，对结果要有人工确认环节，别直接当真。
常见误区
⚠️ 常见踩坑
用有写权限的账号执行模型生成的 SQL，一旦模型或注入构造出删表语句就是灾难；以及不给字段注释只给表名，模型把含义猜错，SQL 语法对但查的是错的口径。
追问
追问 1：库里有几百张表，全塞进 prompt 放不下也烧 token，怎么办？
追问 2：怎么验证模型生成的 SQL 查得对不对，而不是语法对但口径错？
语法对不等于业务对。手段：一是建标注集（问题→标准 SQL/标准结果）做回归评测；二是生成后让模型解释这条 SQL 在算什么，给用户确认；三是对高风险查询展示 SQL 和命中行数让用户预览。关键报表场景必须人工 review，不能盲信。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。