AI 生成执行计划的可信度验证：如何给大模型的 Plan 加上代价保险丝

封面信息图

在数据库内核与人工智能交叉的深水区，利用大语言模型（LLM）或强化学习直接生成复杂 SQL 的物理执行计划（Physical Query Plan / Join Tree），正在从学术概念走向部分前沿数据库的实验室原型。

大模型凭借其对海量历史查询模式的泛化记忆，在面对 10 张表以上的多表关联时，往往能够跳出传统动态规划（DP）或贪心算法的局部最优陷阱，在几毫秒内给出一个极其惊艳的“直觉型 Plan”（例如指定特定的 Join 顺序与 Hash Join 驱动表）。

然而，大模型本质上是一个概率模型。它在 95% 的情况下给出的 Plan 堪称神来之笔，但在剩下的 5% 情况下，模型可能会因为某个细微的参数变动，给出一个将两张千万级大表做无索引嵌套循环（Nested Loop）的“毁灭性 Plan”。

在把 AI 生成的执行计划送进数据库内核物理执行之前，我们必须如何构建一套确定性的“代价保险丝（Cost Guardrails）”，对 AI 的执行计划进行微秒级的可信度验证？

from dataclasses import dataclass
from typing import Dict, Any, Optional

@dataclass
class PhysicalQueryPlan:
plan_id: str
join_order: list
operator_types: Dict[str, str] # 例如: {"join_1": "HASH_JOIN", "scan_1": "INDEX_SCAN"}
estimated_cost: float
confidence_score: float

class AIPlanVerificationEngine:
"""AI 执行计划可信度验证与熔断保险丝引擎"""
def __init__(self, traditional_cost_evaluator, max_cost_deviation_ratio=2.5):
self.cost_evaluator = traditional_cost_evaluator
self.max_deviation = max_cost_deviation_ratio

def verify_and_fuse(self, ai_plan: PhysicalQueryPlan, query_ast: Any, table_stats: Dict) -> PhysicalQueryPlan:
# 1. 结构与语义静态硬约束校验
if not self._validate_plan_validity(ai_plan, query_ast):
raise InvalidPlanException("AI 生成的 Plan 存在逻辑断环或不满足 Join 语义连通性!")

# 2. 调用传统物理代价评估器对 AI Plan 进行独立客观算力定价
independent_cost = self.cost_evaluator.calculate_physical_cost(ai_plan, table_stats)

# 3. 基线对比：获取传统优化器生成的保底 Plan 代价
baseline_plan = self.cost_evaluator.get_baseline_plan(query_ast, table_stats)

# 4. 保险丝熔断判决：如果 AI Plan 的独立代价高于传统基线 2.5 倍，直接熔断抛弃
cost_ratio = independent_cost / max(baseline_plan.estimated_cost, 0.001)
if cost_ratio > self.max_deviation:
# 熔断触发，安全回退至传统基线 Plan
return baseline_plan

# 5. 代价校验通过，打上可信签名并放行
ai_plan.estimated_cost = independent_cost
return ai_plan

def _validate_plan_validity(self, plan: PhysicalQueryPlan, ast: Any) -> bool:
# 校验引用的表集合与 Join Key 是否 100% 覆盖 AST 需求
return set(plan.join_order) == set(ast.referenced_tables)

为什么不能直接信任大模型输出的“自带代价”？

很多团队在接入大模型时，喜欢让大模型在输出 Plan 的同时输出一个“预估 Cost”。这是一个极其危险的误区！大模型输出的所谓 Cost，本质上只是文本概率生成的结果，它根本没有实时读取底层存储引擎当前的 Buffer Pool 脏页率、NVMe SSD 的真实 IOPS 水位以及各分区的统计信息。

核心铁律：AI 只负责提议（Propose），物理代价必须由数据库内核的独立代价计算器（Cost Evaluator）进行严格的代数验算！

[AI 生成执行计划的可信度验证与双轨熔断流水线]

[复杂查询 AST 输入 (例如 8 表 Join)]
│
┌───────────────┴───────────────┐
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ 传统内核优化器基线 │ │ AI 执行计划生成引擎 │
│ (生成 Baseline Plan) │ │ (生成 Candidate Plan)│
└──────────┬──────────┘ └──────────┬──────────┘
│ │
│ ▼
│ ┌─────────────────────┐
│ │ 静态语义与连通性校验 │
│ └──────────┬──────────┘
│ │
▼ ▼
┌─────────────────────────────────────────────────────┐
│ 内核独立代价计算器 (Independent Cost Engine) │
│ – 验算 AI Plan 的真实物理 CPU / IO 代价 │
└──────────────────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 代价保险丝熔断判决 (Cost Fuse) │
│ Cost(AI) < 0.8 * Cost(Base) ──▶ 【放行 AI Plan】 │
│ Cost(AI) >= 2.0 * Cost(Base) ──▶ 【熔断回退基线】 │
└─────────────────────────────────────────────────────┘

代价保险丝的四大硬核校验维度

在生产级验证流水线中，AI Plan 必须连闯四关：

1. 语义连通性与算子拓扑校验（Graph Topology Check）

检查 AI 生成的二叉 Join 树是否包含了查询所需的所有表；检查每个 Join 节点的连接谓词是否合法，坚决杜绝因模型疏漏产生未预期的局部笛卡尔积。

2. 最坏情况代价上界截断（Worst-case Bound）

将 AI Plan 输入内核的物理代价模型（Cost Model）进行独立打分：

如果 AI Plan 的综合代价比传统优化器算出来的基线 Plan 还要高，或者超出安全阈值，系统立即判定模型产生了幻觉，在 0.1 毫秒内触发保险丝熔断，强行回退至传统基线 Plan；
只有当 AI Plan 的真实物理代价明显优于基线 Plan（例如降低 30% 以上），且模型置信度高于 0.85 时，系统才正式放行。

3. 内存配额与算子溢出预警

检查 AI Plan 选取的算子类型。如果 AI 为一张预估 5000 万行的大表推荐了内存 Hash Join，而当前会话的 join_buffer_size 仅有 16MB，验证器会自动给该 Plan 增加“磁盘分片溢出（Spill to Disk）”惩罚分，防止线上内存爆仓。

4. SPM（SQL Plan Management）执行计划基线沉淀

一旦某个 AI Plan 通过了验证并在生产环境中跑出了优异的真实延迟，系统自动将其捕获并持久化进 SPM 计划基线库（SQL Plan Baseline）。后续相同的 SQL 模板直接命中基线，无需每次重复调用大模型推理。

概率归概率，确定归确定。给 AI 的创新翅膀装上冰冷的物理代价保险丝，才是数据库内核兼顾前沿突破与绝对稳定的立身之本。

AI 生成执行计划的可信度验证：如何给大模型的 Plan 加上代价保险丝