Text2SQL 是什么？如何让大模型准确、安全地查询数据库？

🧑‍💻 面试官：用户问“上个月销售额是多少”，Text2SQL 怎么做？

🙋‍♂️ 我：把问题和数据库表结构交给模型，让它生成 SQL，再查询结果。

🧑‍💻 面试官：销售额按下单金额算，还是按实付金额算？退款扣不扣？

🙋‍♂️ 我：需要先给出业务口径，不能让模型自己猜。

🧑‍💻 面试官：SQL 语法正确，也只用了 SELECT，但查出了别的租户的数据。你在哪一步拦住它？

这道题有两道独立的门：查询要符合业务口径，执行要守住数据权限。SQL 能运行，只过了很小的一关。

面试速答（60 秒版）

Text2SQL 就是把用户的自然语言问题转换成 SQL，用数据库中的真实数据回答。

但实际项目里，不能只把表结构塞给模型。模型还需要知道字段含义、表之间怎么关联，以及销售额这类指标的业务口径。问题有歧义时，应该补问，而不是生成一条看起来合理的 SQL。

模型生成以后，应用还要检查允许访问的表和字段、用户的数据范围、查询复杂度和执行时间。数据库连接使用受限的只读权限，租户条件由可信服务控制，不能只靠提示词要求模型遵守。

执行成功以后，再把结果、时间范围和计算口径整理成回答。评测时也要检查结果是否正确、有没有越权和造成高负载，而不只是统计 SQL 的执行成功率。

知识点详解：从一句话到一条可信查询

模型需要的不只是字段名字

假设数据库有 orders 和 order_items 两张表。前者记录订单、实付金额、支付时间和退款情况，后者记录每件商品。

用户问“上个月销售额”，模型如果只知道 amount 是金额，很可能按创建时间求和，再把未支付订单也算进去。

因此，系统需要一份可维护的业务说明：本案例把销售额定义为支付成功订单的实付金额，按支付时间归属月份，退款怎样扣除则需要另行确定。这里的定义只是教学假设，不是所有公司的统一算法。

时间也要明确。例如“上个月”按哪一个时区计算，月底边界如何处理。先把这些条件确认，再生成查询，才能判断 SQL 是否真的回答了用户的问题。

关联两张表，为什么金额可能突然翻倍？

一个订单有多件商品，因此 orders 和 order_items 是一对多关系。

如果模型先连接两张表，再对订单实付金额求和，同一笔订单金额就可能重复出现。一条 SQL 语法完全正确，结果却多算了钱。

因此，提供 Schema 时要解释主键、外键和关联基数。按订单统计时，可以先确定订单集合或进行合适的预聚合；按商品统计时，则要明确商品级金额的计算方式。不能用一个 DISTINCT 随便把重复数字去掉，因为不同订单恰好金额相同也是正常的。

比起让模型猜整套复杂表结构，常见指标可以先提供经过确认的视图或查询模板。模型只填时间、产品等受控条件，容易把结果核对清楚。

生成 SQL 以后，怎样进入执行层？

模型给出的 SQL 应当先进入验证模块，而不是直接送到生产库。

验证模块可以解析语法结构，检查语句类型、表字段白名单、允许的函数和查询范围。只判断开头有没有 SELECT 不够，注释、嵌套查询及函数调用都可能让这种字符串检查失效。

随后，可信服务根据登录身份确定租户和对象权限。在复杂查询上，简单地往末尾拼一个 tenant_id 条件也可能漏掉子查询或其他数据入口。更稳妥的方式是限定可访问视图、受控模板，或者按数据库能力建立可靠的数据范围隔离。

最后，再由受限的数据库账号执行。只读账号能降低写入风险，却仍可能读取不该看到的敏感数据，所以最小权限要具体到数据对象。LangChain 的 SQL Agent 文档也明确提醒：示例工具不是生产安全方案，需要收紧数据库权限并增加业务校验。

只读查询，为什么还需要限额？

假设 SQL 连接了几张大表，并扫描整年的交易数据。它虽然没有修改记录，也可能拖慢其他请求。

因此，执行端需要查询超时、连接和并发限制、返回行数限制，以及必要的计划检查。LIMIT 限制输出行数，不保证前面的扫描和聚合成本也很小。

分析场景可以使用合适的只读副本或分析库，但要向用户说明数据延迟。查不到最新交易时，不能把副本尚未同步说成“没有这笔订单”。

面试官继续追问

查询报错，能不能把错误交给模型重写？

可以有限次修复，例如字段不存在或者类型不匹配。

但权限拒绝不能被当成“换一张表再试试”的提示，原始错误也要避免暴露敏感结构。每次修复后的 SQL 都要重新验证，不能因为已经检查过第一版就跳过执行门禁。

SQL 和标准答案写得不一样，怎么评测？

重点是业务结果是否符合要求，而不只是字符串是否相同。

准备带已知结果的测试数据库，覆盖空结果、跨月边界、退款、一对多关联和越权访问。比较结果时要按业务约定处理排序、精度和空值；同时检查是否使用了不允许的数据。结果碰巧正确，不代表查询逻辑可靠。

所有问题都应该开放生成 SQL 吗？

不应该。订单总额、日销售额这类固定指标，受控模板通常更合适。

探索性分析才可能需要更开放的查询，但也要限定表、预算和用途。涉及写数据时，应设计明确的业务操作接口与审批，不把 Text2SQL 直接升级成任意 SQL 执行器。

面试速记卡

• Text2SQL：自然语言转换成查询，再用真实结果回答。

• 正确前提：字段含义、关联基数、指标口径和时间范围清楚。

• 安全执行：结构校验、数据权限与数据库最小权限分层处理。

• 性能边界：只读和 LIMIT 都不等于低成本。

• 评测重点：结果正确、条件覆盖、无越权，而非只看语法成功。