DBCooker深度解析：当大语言模型学会给数据库「写代码」，SIGMOD 2026 论文揭示的自动化革命

引言：数据库开发的「最后一公里」难题

在数据库的世界里，有一项工作长期被视为「黑魔法」——给数据库添加原生函数。

你有没有想过，当你写下 date_trunc('hour', timestamp '2001-02-16 20:38:40') 时，数据库是怎么知道要返回 2001-02-16 20:00:00 的？这背后，是数据库开发者们用数万行代码精心编织的「原生函数」系统。这些函数是数据库的内置工具箱，从计算平方根、截断时间戳，到拼接字符串、处理JSON数据，每一项功能都需要开发者在数据库内核深处逐一实现。

然而，这项工作极其困难。以PostgreSQL为例，原生函数相关代码光是两跳以内的依赖就超过11万9千行；DuckDB的GitHub仓库里，和函数相关的问题单多达3791条。每写一个新函数，开发者需要同时在多个文件里注册、实现、引用内部接口，稍有不慎就会酿成编译错误或逻辑漏洞。

更严峻的是，随着数据库迁移需求的爆发，这项工作的代价正在急剧攀升。企业要把Oracle数据库迁移到PostgreSQL，需要把Oracle独有的功能在新系统里重新实现，这项工作占到整个迁移预算的30%到60%，平均每一千行代码需要花费40到80个小时。

2026年4月，上海交通大学主导、联合清华大学、新加坡国立大学以及蚂蚁集团共同完成的研究成果，发表于ACM数据管理顶级期刊SIGMOD 2026。他们提出的DBCooker系统，让大语言模型学会了给数据库「写代码」——在SQLite、PostgreSQL和DuckDB三个主流数据库上，平均准确率比当前最强的对手（包括Anthropic的Claude Code、阿里巴巴的Qwen Code等）高出34.55%，并成功为最新版SQLite（v3.50）添加了17个此前完全不存在的新函数。

这不仅仅是一次技术突破，更是一场关于「如何让AI真正理解复杂系统架构」的深度探索。

一、问题的本质：为什么AI写数据库函数这么难？

1.1 原生函数：数据库的「内核级」代码

要理解DBCooker的价值，必须先理解它要解决的问题到底有多难。

数据库的原生函数（Native Functions）和普通的应用层代码完全不同。它们运行在数据库内核空间，直接与存储引擎、查询优化器、执行器交互。一个看似简单的SQL函数调用，在数据库内部可能触发一系列复杂的底层操作。

以PostgreSQL的 date_trunc() 函数为例。这个函数的功能听起来简单：把一个时间戳「截断」到指定精度。但在数据库内核层面，这一个SQL关键字对应的是四个不同的底层函数单元：

// PostgreSQL 内核中的 date_trunc 实现结构
// 1. 处理带时区时间戳
Datum timestamptz_trunc(PG_FUNCTION_ARGS);

// 2. 处理时间间隔
Datum interval_trunc(PG_FUNCTION_ARGS);

// 3. 处理带特定时区的时间戳
Datum timestamptz_trunc_zone(PG_FUNCTION_ARGS);

// 4. 内部辅助函数
Datum timestamptz_trunc_internal(PG_FUNCTION_ARGS);

开发者必须把这四个单元分别注册在系统目录文件 pg_proc.dat 里，然后在 src/backend/utils/adt/timestamp.c 这个源文件里逐一实现，还要正确引用数十个数据库内部的宏和工具函数：

// 获取输入参数的宏
PG_GETARG_TEXT_PP(n)

// 返回结果的宏
PG_RETURN_TIMESTAMPTZ(result)

// 错误处理宏
ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                errmsg("invalid precision")));

1.2 三个致命障碍

研究团队通过大量观察，总结出了AI写数据库函数的三个主要障碍：

障碍一：一对多的隐式映射

一个SQL层面的函数，在数据库内核里往往对应多个分工不同的底层单元。这种映射关系深埋在代码仓库的隐式约定里，没有明确文档，全靠资深工程师的经验。

比如，当你要实现一个聚合函数 covar_pop()（计算协方差），你需要知道它需要三个底层单元：

// 聚合函数的三个必须实现的底层单元
static void covarPopStep(AggState *aggstate, ...);    // 逐行累加
static Datum covarPopFinalize(AggState *aggstate);     // 计算最终值
static void covarPopInverse(AggState *aggstate, ...);  // 窗口函数逆运算

如果你只实现了前两个，忘记第三个，代码在编译时会通过，但在执行窗口函数时会崩溃。

障碍二：海量引用中的精准寻找

数据库代码仓库极其庞大。以SQLite为例，每个文件平均有2619个可引用的函数和宏，但一个原生函数真正需要用到的，平均只有13.73个。在这片汪洋大海里找到那十几颗关键的「明珠」，对AI来说并不容易。

Claude Code在合成数据库函数时，有63.70%的操作时间花在了「搜索仓库」和「读取文件」上，真正用于「生成代码」的时间只占4.95%。换句话说，它把大部分精力用来在浩如烟海的代码文件里找方向，而不是实实在在地写代码。

障碍三：千人千面的复杂度

不同的函数，实现难度天差地别：

用一套固定流程统一对待它们，必然顾此失彼。

1.3 现有AI工具的失败模式

研究团队统计了通用AI工具在数据库函数合成任务上的错误分布：

这揭示了一个核心问题：通用AI工具不了解数据库内部的注册规范，经常把函数声明放错地方，或者引用根本不存在的内部接口。即使把正确的文件路径、函数声明和引用接口全部提前告诉它们，准确率仍然比DBCooker低22.56%——说明数据库函数合成的难点，不仅仅在于「找到正确的文件」，更在于生成符合数据库内核规范的代码本身。

二、DBCooker的「烹饪哲学」：三大模块协同作战

研究团队把这套系统命名为「DBCooker」——数据库（DB）加烹饪者（Cooker）。整套系统的逻辑，像极了一个专业厨师的工作方式：先备料，再按方煮，最后严格验收。

2.1 模块一：函数特征化（Function Characterization）—— 精准备料

在下锅之前，必须先弄清楚这道菜需要什么食材。函数特征化模块负责在开始写代码之前，把一个SQL函数需要的所有关键信息摸清楚。

2.1.1 双路信息汇集

系统从两条路径汇集信息：

路径一：解析官方文档

# 从 PostgreSQL 文档提取函数描述
doc_info = {
    "name": "date_trunc",
    "description": "truncate timestamp to specified precision",
    "syntax": "date_trunc(field, source)",
    "examples": [
        "date_trunc('hour', timestamp '2001-02-16 20:38:40')",
        "-- returns: 2001-02-16 20:00:00"
    ]
}

路径二：查询系统目录

# 从 PostgreSQL 系统目录提取精确签名
catalog_info = {
    "proname": "date_trunc",
    "proargtypes": ["text", "timestamp with time zone"],
    "prorettype": "timestamp with time zone",
    "prolang": "internal",
    "prosrc": "timestamptz_trunc"
}

两路信息合并成统一的JSON格式，就得到了一份完整的「函数档案」。

2.1.2 图遍历识别底层单元

备好基础资料之后，系统采用「图遍历」方法识别所有相关的底层函数单元：

def identify_bottom_units(sql_function, code_repo):
    """
    从SQL函数出发，遍历调用关系图，找出所有底层单元
    """
    # 构建调用关系图
    call_graph = build_call_graph(code_repo)
    
    # 从SQL关键字出发进行广度优先遍历
    start_node = find_entry_point(sql_function)
    visited = set()
    units = []
    
    queue = [start_node]
    while queue:
        node = queue.pop(0)
        if node in visited:
            continue
        visited.add(node)
        
        # 排除全局通用单元
        if not is_global_utility(node):
            units.append(node)
        
        # 继续遍历下游
        for callee in call_graph.get(node, []):
            if callee not in visited:
                queue.append(callee)
    
    return units

2.1.3 成对比较提取模板

找到所有相关单元后，系统会对同一类别的函数做「成对比较」——把两个同类函数的代码对齐，找出共同的固定部分和各自不同的变化部分：

// 固定部分：可复用的模板
Datum
${FUNCTION_NAME}(PG_FUNCTION_ARGS)
{
    ${ARG_TYPE} arg1 = PG_GETARG_${ARG_TYPE}(0);
    ${RESULT_TYPE} result;
    
    // 变化部分：需要AI填写的核心逻辑
    ${CORE_LOGIC}
    
    PG_RETURN_${RESULT_TYPE}(result);
}

2.2 模块二：函数合成操作（Function Synthesis）—— 按方下厨

有了备好的「食材」，接下来就是实际下厨炒菜的过程。函数合成模块包含三个递进的环节。

2.2.1 环节一：伪代码计划生成

在真正写代码之前，系统先让AI生成一份详细的实现方案——不是真正的代码，而是像施工图纸一样的「骨架」：

# 伪代码计划示例
function: date_trunc
units:
  - name: timestamptz_trunc
    file: src/backend/utils/adt/timestamp.c
    blocks:
      - type: argument_extraction
        macros:
          - PG_GETARG_TEXT_PP(0)  # precision
          - PG_GETARG_TIMESTAMPTZ(1)  # timestamp
      - type: precision_parsing
        calls:
          - DecodeSpecialTimeField  # 解析精度字符串
      - type: truncation_logic
        calls:
          - timestamp_trunc_internal
      - type: result_return
        macros:
          - PG_RETURN_TIMESTAMPTZ(result)

为了确保计划质量，系统会同时生成多份候选计划，然后用评分公式筛选：

def score_plan(plan, code_repo):
    """
    评估伪代码计划的质量
    """
    # 可信度：计划中列出的引用接口实际存在的比例
    credibility = 0
    total_refs = 0
    for ref in plan.references:
        if exists_in_repo(ref, code_repo):
            credibility += 1
        total_refs += 1
    credibility /= total_refs
    
    # 简洁性：计划列出的函数单元数量不要过于冗余
    simplicity = 1 / (1 + len(plan.units) * 0.1)
    
    # 综合得分
    return 0.7 * credibility + 0.3 * simplicity

2.2.2 环节二：填空式代码合成

有了计划骨架后，实际写代码的过程被设计成「填空题」而非「作文题」：

def fill_template(template, plan, ai_model):
    """
    基于模板填空生成代码
    """
    # 固定部分直接复用
    code = template.fixed_parts
    
    # 变化部分由AI填写
    for slot in template.slots:
        context = build_context(slot, plan)
        generated = ai_model.generate(context, max_tokens=500)
        code = code.replace(slot.placeholder, generated)
    
    return code

系统会同时生成多个候选实现，然后用「少数服从多数」投票策略：

def vote_best_implementation(candidates):
    """
    从多个候选实现中投票选出最佳方案
    """
    code_hashes = [hash(c.code) for c in candidates]
    counter = Counter(code_hashes)
    best_hash, _ = counter.most_common(1)[0]
    return [c for c in candidates if hash(c.code) == best_hash][0]

此外，还有一个「自动降级」机制：如果填空模板质量不够好，系统会逐步降低对模板的依赖：

class TemplateDecay:
    def __init__(self, initial_weight=1.0, decay_rate=0.2):
        self.weight = initial_weight
        self.decay_rate = decay_rate
    
    def on_failure(self):
        """每次失败后降低模板权重"""
        self.weight *= (1 - self.decay_rate)
        if self.weight < 0.1:
            self.weight = 0  # 完全切换到自由生成模式
    
    def should_use_template(self):
        return self.weight > 0.3  # 权重太低则放弃模板

2.2.3 环节三：三阶段代码验证

代码写完之后，要经历三关考核：

第一关：语法检查

def syntax_check(code, language='c'):
    """
    使用ANTLR进行语法检查
    """
    lexer = CLexer(InputStream(code))
    parser = CParser(CommonTokenStream(lexer))
    parser.translationUnit()  # 尝试解析
    
    if parser.getNumberOfSyntaxErrors() > 0:
        return False, parser.getErrorMessages()
    return True, None

第二关：合规检查

# 直接调用数据库编译工具
cd postgresql && ./configure && make install

# 检查编译输出
if [ $? -eq 0 ]; then
    echo "合规检查通过"
else
    echo "合规检查失败: $(make log 2>&1)"
fi

第三关：语义验证

def semantic_verification(function, test_cases):
    """
    自动生成测试用例并验证语义正确性
    """
    # AI生成测试用例
    test_cases = generate_test_cases(function, categories=[
        'normal_inputs',      # 正常输入
        'boundary_cases',     # 边界情况
        'null_handling',      # NULL处理
        'type_coercion',      # 类型转换
        'error_conditions'    # 错误条件
    ])
    
    # 执行测试
    results = []
    for tc in test_cases:
        actual = execute_sql(tc.query)
        expected = tc.expected
        results.append(actual == expected)
    
    return all(results)

三关中任何一关不过，系统都会把错误信息反馈给AI，让它修改代码，直到全部通过。

2.3 模块三：自适应工具编排（Adaptive Tool Orchestration）—— 灵活调度

不同函数的复杂度差异巨大，不能用固定流程一刀切。自适应工具编排模块负责智能地串联所有操作。

2.3.1 标准化工具封装

每个可用操作都被包装成标准化的「工具」：

class Tool:
    def __init__(self, name, execute_func, cost_estimate):
        self.name = name
        self.execute = execute_func
        self.cost = cost_estimate

# 定义工具集
tools = [
    Tool('plan', generate_pseudo_plan, cost=1),
    Tool('code', synthesize_code, cost=2),
    Tool('syntax', check_syntax, cost=0.5),
    Tool('compile', compile_and_integrate, cost=3),
    Tool('test', semantic_verification, cost=2),
]

2.3.2 历史经验库

系统维护一个「历史经验库」，记录过去合成类似函数时用过的操作序列：

{
    "function_type": "math",
    "complexity": "simple",
    "successful_paths": [
        ["plan", "code", "syntax", "compile"],
        ["code", "compile", "test"],
        ["plan", "code", "compile"]
    ],
    "average_steps": 3.2,
    "success_rate": 0.92
}

2.3.3 动态决策

AI控制器实时决定下一步调用哪个工具：

def decide_next_tool(current_state, history_db, tools):
    """
    基于当前状态和历史经验决定下一步操作
    """
    # 从历史库中检索相似案例
    similar_cases = history_db.query(
        function_type=current_state.function_type,
        complexity=current_state.complexity
    )
    
    # 提取参考策略
    strategies = extract_strategies(similar_cases)
    
    # 综合最省事、最费劲、中间水平三种做法
    best_strategy = combine_strategies(
        strategies.min_cost,
        strategies.max_cost,
        strategies.avg_cost
    )
    
    # 结合当前状态调整
    return select_tool(current_state, best_strategy, tools)

三、实验结果：数据说话

3.1 整体表现

研究团队在SQLite、PostgreSQL和DuckDB三个主流数据库上进行了全面测试：

与竞争对手的对比：

3.2 按难度分层的表现

关键洞察：随着函数复杂度的增加，通用AI工具的能力急剧退化，而DBCooker的专项设计使其在复杂场景下依然保持稳定。

3.3 按函数类别的表现

DBCooker在各类别上表现稳定均匀，而竞争对手在不同类别上表现参差不齐，尤其在数学函数这类「看起来简单实则充满底层细节」的函数上，大多数LLM方法合规准确率仅有6.67%到16.67%。

3.4 消融实验：每个模块的贡献

关键洞察：

• 函数特征化对PostgreSQL最为关键（降幅47.37个百分点），说明对于结构复杂的数据库，预先理解函数组成至关重要
• 三阶段验证对PostgreSQL更是生死攸关（降幅71.72个百分点），反映了PostgreSQL内部依赖关系的极度复杂性
• 计划和验证相辅相成，缺一不可

四、实战案例：给SQLite添加17个新函数

研究团队做了一个更有野心的实验：把PostgreSQL和DuckDB里有、但SQLite里没有的函数，用DBCooker合成到SQLite里。

4.1 成功率对比

4.2 典型案例：covar_pop()

函数描述：计算协方差的聚合函数

DBCooker的实现：

// SQLite 原生函数注册
static void covarPopStep(sqlite3_context *ctx, int argc, sqlite3_value **argv) {
    CovarCtx *p = sqlite3_aggregate_context(ctx, sizeof(CovarCtx));
    if (p) {
        double x = sqlite3_value_double(argv[0]);
        double y = sqlite3_value_double(argv[1]);
        p->sum_x += x;
        p->sum_y += y;
        p->sum_xy += x * y;
        p->count++;
    }
}

static void covarPopFinalize(sqlite3_context *ctx) {
    CovarCtx *p = sqlite3_aggregate_context(ctx, 0);
    if (p && p->count > 0) {
        double mean_x = p->sum_x / p->count;
        double mean_y = p->sum_y / p->count;
        double covar = (p->sum_xy / p->count) - (mean_x * mean_y);
        sqlite3_result_double(ctx, covar);
    } else {
        sqlite3_result_null(ctx);
    }
}

static void covarPopInverse(sqlite3_context *ctx, int argc, sqlite3_value **argv) {
    CovarCtx *p = sqlite3_aggregate_context(ctx, sizeof(CovarCtx));
    if (p) {
        double x = sqlite3_value_double(argv[0]);
        double y = sqlite3_value_double(argv[1]);
        p->sum_x -= x;
        p->sum_y -= y;
        p->sum_xy -= x * y;
        p->count--;
    }
}

// 注册
sqlite3_create_function(db, "covar_pop", 2, SQLITE_UTF8, 0,
                        0, covarPopStep, covarPopFinalize);

Qwen Code的错误：虽然正确注册了声明，但没有实现 covarPopInverse，导致编译时报错"WAGGREGATE宏中xInverse未声明"。

4.3 典型案例：regexp_split_to_array()

函数描述：用正则表达式分割字符串为数组

DBCooker的正确引用：

// 使用SQLite内部接口
sqlite3_value_text(argv[0]);
sqlite3_str_new(db);
sqlite3_str_appendf(str, "%s", pattern);

其他方法的错误：

// 错误：引用了不存在的外部接口
sqlite3re_compile(pattern);  // 在标准发行版中不存在
sqlite3re_match(re, text);   // 在标准发行版中不存在

五、技术启示：专项化设计的胜利

5.1 为什么通用AI工具在数据库领域失效？

DBCooker的成功揭示了一个重要规律：面对高度结构化、规范严格、内部依赖复杂的特定代码合成任务，专项化设计比通用方法有着明显的优势空间。

通用代码智能体（如Claude Code、Qwen Code）的设计假设是：

• 代码仓库有良好的模块化结构
• 接口和实现的关系相对清晰
• 可以通过检索和试错逐步收敛

但数据库内核代码完全不同：

• 系统目录和实现代码分散在不同文件
• 函数注册涉及隐式的约定和规范
• 错误往往是编译级别的，无法通过简单试错修复

5.2 三层抽象的价值

DBCooker的三层抽象设计值得借鉴：

这套方法论可以推广到其他类似的复杂系统代码合成任务：

[领域理解] → [模板提取] → [填空生成] → [分层验证] → [自适应编排]

5.3 与其他领域的对比

六、未来展望与挑战

研究团队在论文中坦诚地指出了三个深层挑战：

6.1 代码库碎片化 vs 长上下文推理

PostgreSQL源代码超过一百万行，声明和实现分散在不同文件。即便未来AI模型能处理超长上下文，把整个代码库塞进去也会带来高昂的推理成本，而且AI很可能在信息量过大时迷失方向。

DBCooker的解决方案：通过函数特征化提前精准定位相关内容，避免「大海捞针」式的搜索。

6.2 确定性要求 vs 概率性生成

数据库函数必须在所有情况下都输出正确结果，没有「大体上正确」这一说。而AI生成内容的本质是概率性的。

DBCooker的解决方案：通过外部强制执行的伪代码计划和三阶段渐进验证，把概率性输出转化为可验证的正确实现。

6.3 版本迭代 vs 训练数据滞后

数据库函数的签名、内部宏用法、系统目录结构会随版本更新而变化。AI模型训练时接触的是历史数据，难以跟上最新版本。

DBCooker的解决方案：通过动态检索当前版本的实现惯例，用自适应工具编排强制执行，无需重新训练模型。

七、实践指南：如何使用DBCooker

7.1 环境准备

# 克隆仓库
git clone https://github.com/weAIDB/DBCooker.git
cd DBCooker

# 安装依赖
pip install -r requirements.txt

# 准备目标数据库源码
# 以SQLite为例
wget https://www.sqlite.org/2026/sqlite-autoconf-3500000.tar.gz
tar xzf sqlite-autoconf-3500000.tar.gz

7.2 添加新函数

from dbcooker import DBCooker

# 初始化
cooker = DBCooker(
    db_type='sqlite',
    db_source='./sqlite-autoconf-3500000',
    llm_backend='claude'  # 或 'gpt', 'qwen'
)

# 定义要添加的函数
function_spec = {
    'name': 'monthname',
    'description': 'returns the month name from a date',
    'syntax': 'monthname(date)',
    'return_type': 'text',
    'examples': [
        "monthname('2026-04-23') -- returns 'April'"
    ]
}

# 执行合成
result = cooker.synthesize(function_spec)

# 查看结果
print(f"Generated code: {result.code}")
print(f"Compilation: {'passed' if result.compiles else 'failed'}")
print(f"Tests: {'passed' if result.tests_passed else 'failed'}")

7.3 集成到数据库

# 将生成的代码集成到SQLite源码
cp result/generated_func.c sqlite-autoconf-3500000/src/

# 重新编译
cd sqlite-autoconf-3500000
./configure && make

# 测试
sqlite3 test.db "SELECT monthname('2026-04-23');"
# 输出: April

八、总结

DBCooker代表了AI代码生成从「通用化」向「专业化」演进的重要一步。它证明了：

1. 领域知识至关重要：通用AI工具在复杂系统代码合成上效果有限，专项化设计有明显的优势空间
2. 结构化方法优于端到端：把任务分解为理解、规划、执行、验证四个阶段，比端到端生成更可靠
3. 验证是不可或缺的环节：在确定性要求高的领域，外部验证机制是把概率性生成转化为确定正确的关键

对于数据库开发者和企业IT团队而言，这意味着那些长达数月的数据库迁移项目，其中最耗时的函数重实现部分，未来或许能够得到切实的自动化支持——而不再只是「AI能帮我搜索一些参考代码」这种程度的辅助。

论文信息：

• 标题：DBCooker: Automating Database Native Function Synthesis with Large Language Models
• 发表：SIGMOD 2026, Proceedings of the ACM on Management of Data, Vol. 4, No. 3, Article 141
• DOI：10.1145/3802018
• GitHub：https://github.com/weAIDB/DBCooker

本文基于SIGMOD 2026论文《DBCooker: Automating Database Native Function Synthesis with Large Language Models》撰写，感谢上海交通大学、清华大学、新加坡国立大学和蚂蚁集团研究团队的开创性工作。