DeepSeek 实战：从零构建 Text2SQL 数据平权应用

作者：袖梨 2026-09-16

让非技术人员直接用自然语言查询数据库，是 Text2SQL 最直观的应用价值，但从生成一条可执行 SQL 到构建可靠的数据应用，中间仍有不少工程问题。下面将使用 DeepSeek API 和 SQLite 完成一个轻量原型，并重点分析 Schema 提供、写操作校验、多表查询与事务一致性等关键环节。

前言

在“Vibe Coding”（氛围编程）时代，代码开发的平权正在发生，而数据平权（Data Democracy） 也紧随其后。Text2SQL 技术让非技术人员只需通过自然语言描述，就能直接与数据库对话并获取结果。

今天，我们将基于 SQLite 和 DeepSeek API，从零构建一个轻量级的 Text2SQL 系统。本文不仅包含核心代码实现，还会分享在实际开发中遇到的“数据库锁”、“多表 Schema 缺失”以及“事务处理”等实战踩坑经验。

一、 基础环境与数据准备

1.1 为什么选择 SQLite？

正如我们的 readme106.md 笔记中提到的：

作为系统内置的文件型数据库，SQLite 是一个轻量级的数据库，无需安装，无需配置，无需管理。

这让它成为我们验证 Text2SQL 逻辑的最佳沙盒。

1.2 初始化大模型客户端

我们通过 OpenAI SDK 兼容的方式接入 DeepSeek：

python

from openai import OpenAI
client = OpenAI(
    api_key="sk-8dbb...", # 你的 DeepSeek API Key
    base_url="https://api.deepseek.com/v1"
)

1.3 创建员工表并插入数据

我们创建一个 employees 表，并尝试批量插入数据。

python

import sqlite3 
conn = sqlite3.connect("test.db")
# 创建一个游标对象，执行sql操作
cursor = conn.cursor()
cursor.execute("""
CREATE TABLE IF NOT EXISTS employees (
    id INTEGER PRIMARY KEY,
    name TEXT,
    department TEXT,
    salary INTEGER
)
""")

sample_data = [
    (6, "胡航", "销售", 50000),
    (7, "牛奶", "工程", 75000),
    (8, "倩倩", "销售", 60000),
    (9, "月月", "工程", 80000),
    (10, "黄仁勋", "市场", 55000),
]
# insertmany 批量插入，提升性能
cursor.executemany(
    "INSERT INTO employees VALUES (?,?,?,?)",
    sample_data
)
conn.commit()

⚠️ 踩坑提示：  在实际运行 Notebook 时，很容易遇到 OperationalError: database is locked。这是因为 SQLite 默认写锁机制较严格，特别是在 Jupyter 反复执行同一个 Cell 或存在未关闭的连接时。建议在重跑前 conn.close()，或者确保每次只运行一次初始化逻辑。

二、 构建 Text2SQL 核心引擎

2.1 提取数据库 Schema

大模型需要知道表结构才能写 SQL。注释中写得非常清楚：Schema 应详细描述每个表的字段和类型，这有助于模型理解表的结构和关联。

python

# 获取数据库Schema
# SQLite命令，查看employees表的列名、类型等结构信息。
schema = cursor.execute("PRAGMA table_info(employees)").fetchall()
print(schema)

# 列表推导式
# 使用 f-string（格式化字符串字面量），将列名和类型拼接成一个字符串。
schema_str = "CREATE TABLE EMPLOYEES (n" + "n".join([f"{col[1]} {col[2]}" for col in schema]) + "n)"
print("数据库Schema:")
print(schema_str)

2.2 定义 Prompt 与 DeepSeek 调用

python

# 销售部门平均工资多少？先分组再算平均
# text2sql 数据平权
# vibe coding 平权了代码开发
def ask_deepseek(query, schema):
    # f 作为模版
    prompt = f"""
    这是一个数据库的Schema：
    {schema}
    根据这个Schema，请输出一个SQL查询来回答以下问题。
    只输出SQL 查询语句本身，不要使用任何Markdown格式，
    不要包含反引号、代码块标记或者额外说明。
    问题:{query}
    """
    response = client.chat.completions.create(
        model = "deepseek-v4-flash",
        max_tokens = 2048,
        messages=[{
            "role":"user",
            "content":prompt
        }]
    )
    return response.choices[0].message.content

三、 CRUD 实战演练

接下来我们看看大模型对于自然语言的 SQL 生成能力。

  • 查询操作：
    question = "工程部门员工的姓名和工资是多少？"
    模型输出：SELECT name, salary FROM EMPLOYEES WHERE department = '工程'; ✅
  • 插入操作：
    question = "在销售部门增加一个新员工，姓名为张三，工资为45000"
    模型输出：INSERT INTO EMPLOYEES (name, department, salary) VALUES ('张三', '销售', 45000); ✅
  • 更新操作：
    question = "将倩倩的工资调整为55000"
    模型输出：UPDATE EMPLOYEES SET salary = 55000 WHERE name = '倩倩'; ✅
  • ❌ 删除操作的“幻觉” ：
    question = "删除市场部门的黄仁勋"
    模型却输出了：DELETE FROM EMPLOYEES WHERE id = 12 AND name = '张三';
    分析：大模型在这里产生了严重的幻觉，因为 张三 是上一个上下文插入的，模型将其与 黄仁勋 的删除混淆，并错误地估计了 id=12。这也告诉我们，生产环境中必须对 Text2SQL 生成的增删改语句进行严格校验或引入 Human-in-the-loop。

四、 进阶：多表查询与事务管理

结合 readme106.md 中的设计，我们要进一步引入 departments 表（包含 id, name, manager）。

4.1 唯一性约束踩坑

在尝试插入部门数据时：

python

cursor.execute("""
CREATE TABLE IF NOT EXISTS departments(
    id INTEGER PRIMARY KEY,
    name TEXT,
    manager TEXT
)
""")
sample_departments = [
    (1, "销售", "王经理"),
    (2, "工程", "李经理"),
    (3, "市场", "张经理")
]
# 执行 executemany 时可能会遇到 IntegrityError

如果多次运行，会遇到 IntegrityError: UNIQUE constraint failed: departments.id。这是因为 CREATE TABLE IF NOT EXISTS 不会清空表，主键冲突会导致插入失败。建议使用 INSERT OR IGNORE 或事先 DROP TABLE。

4.2 多表查询的 Schema 盲区

当我们提出需求：question = "根据两个表之间的关系，列出每个部门的员工人数和平均工资"
模型给出：

sql

SELECT department, COUNT(*) AS employee_count, AVG(salary) AS average_salary FROM EMPLOYEES GROUP BY department;

? 发现问题了吗？
生成的 SQL 只用了 EMPLOYEES 表，根本没有连表（JOIN）departments。这是因为我们在构建 schema_str 时，只提取了 employees 表的 Schema，模型根本不知道 departments 表的存在！这提醒我们，在做多表 Text2SQL 时，提供全量 Schema 至关重要。

4.3 引入事务（Transaction）

针对 readme106.md 中提到的业务场景：

  • 订单 order
  • 商品 product count-1
  • 付款 pay

在 Text2SQL 落地到实际业务时，我们必须引入事务（Transaction） 。单纯让 LLM 生成一句 SQL 是不够的，因为像“生成订单”、“扣减库存”、“付款”往往需要多条 SQL 保持原子性。一旦其中某一步骤失败，必须整体回滚（Rollback），确保数据一致性。

python

try:
    # 开启事务
    cursor.execute("BEGIN TRANSACTION")
    # 大模型生成的三条相关SQL
    # cursor.execute(sql_order)
    # cursor.execute(sql_product)
    # cursor.execute(sql_pay)
    conn.commit()
except Exception as e:
    conn.rollback()

五、 总结与展望

通过这个实战项目，我们验证了 Text2SQL 数据平权的可行性。大模型在处理标准 CRUD 甚至部分聚合查询（如 GROUP BY）时已经游刃有余。

但在走向生产的过程中，我们依然需要警惕：

  1. Schema 注入不全：多表查询时模型容易盲目自信，提供完整详尽的 Schema（包括外键关系）是成功的关键。
  2. 大模型的幻觉：如删除操作的乌龙，对于变更类 SQL 必须谨慎。
  3. 事务保障：复杂业务链路不能依赖单条 SQL，必须在应用层利用事务兜底。

相关文章

精彩推荐