AI 数据库内核优化与智能查询计划生成：模型输出异常时的降级边界

模型参与查询计划评分时，要先定义它失效后的行为。遇到未覆盖的 SQL、数据分布变化或推理超时，优化器应能忽略模型结果，继续走已有的代价估算路径。本文讨论这条降级链路的边界和验证方式。

模型调用不该成为优化器的单点依赖。这里的目标不是承诺固定切换耗时，而是让模型超时、输出不合法或熔断时，查询仍能回到已验证的 CBO 路径；超时阈值应由本机负载和查询预算决定。

---

1. 双轨并行查询优化架构

为了防止 AI 模型决策失控导致数据库 Thread Block 或 I/O 暴涨，内核优化器需要采用“双轨决策与前置校验”架构。在此架构中，AI Optimizer 不直接掌控执行计划的下发权，而是作为 Candidate Plan 生成器存在。

AI 生成的物理计划提交给执行器前，应经过语义校验和代价边界检查。推理超时或校验失败时，调度器直接选择传统 CBO 结果；切换预算要通过压测确定。

隔离层放在 Plan Dispatcher。AI 推理放入独立的任务池，并设置并发数和队列上限，避免它与数据库关键线程争抢资源。

---

2. 异常输入与超时熔断判定逻辑

AI 数据库内核在处理未知 SQL 结构或异常参数时，常见故障模式表现为三类：

1. 结构异常：SQL 包含多层嵌套子查询或极其罕见的 JOIN 条件，导致特征向量生成器（Vector Embedder）输出异常矩阵。
2. 推理超时：推理队列积压，或跨进程 RPC 等待超过当前请求预算。
3. 基数估算失控：模型输出的 Row Estimate 值为 negative 或 NaN，导致选择错误的 JOIN 方式（例如将 1000 万行数据误判为 10 行而走 Nested Loop Join）。

防线构建需要做到“早判断、硬隔离”。对于向量提取失败或高阶语法，直接绕过 AI 引擎；对于超时，使用轻量级 Cancel Signal 强行中断推理线程。

---

3. 降级调度器示例

以下展示基于 Go 语言构建的内核级智能计划调度与快速降级组件。包含 Context 超时控制、滑动窗口熔断器以及备用 CBO 兜底调度。

package optimizer

import (
	"context"
	"errors"
	"fmt"

	"math"
	"sync/atomic"
	"time"
)

var (
	ErrInferenceTimeout = errors.New("ai optimizer inference timeout")
	ErrInvalidPlan      = errors.New("ai generated plan invalid or cost unbounded")
	ErrCircuitOpened    = errors.New("ai optimizer circuit breaker is open")
)

type PhysicalPlan struct {
	PlanID    string
	Cost      float64
	IsAIBased bool
	Operators []string
}

type CircuitBreaker struct {
	failureThreshold int32
	consecutiveFails int32
	lastFailureTime  time.Time
	state            int32 // 0: Closed, 1: Open
}

func (cb *CircuitBreaker) Allow() bool {
	return atomic.LoadInt32(&cb.state) == 0
}

func (cb *CircuitBreaker) RecordFailure() {
	fails := atomic.AddInt32(&cb.consecutiveFails, 1)
	if fails >= cb.failureThreshold {
		atomic.StoreInt32(&cb.state, 1)
	}
}

func (cb *CircuitBreaker) RecordSuccess() {
	atomic.StoreInt32(&cb.consecutiveFails, 0)
	atomic.StoreInt32(&cb.state, 0)
}

type QueryOptimizer struct {
	cb         *CircuitBreaker
	aiTimeout  time.Duration
	maxCostLimit float64
}

func NewQueryOptimizer(timeout time.Duration, maxCost float64) *QueryOptimizer {
	return &QueryOptimizer{
		cb:           &CircuitBreaker{failureThreshold: 5},
		aiTimeout:    timeout,
		maxCostLimit: maxCost,
	}
}

// OptimizePlan 调度主入口：优先AI计划，异常快速降级至传统CBO
func (opt *QueryOptimizer) OptimizePlan(ctx context.Context, sql string) (*PhysicalPlan, error) {
	if opt.cb.Allow() {
		plan, err := opt.tryAIInference(ctx, sql)
		if err == nil && opt.validatePlan(plan) {
			opt.cb.RecordSuccess()
			return plan, nil
		}
		// 记录故障并快速触发表级降级
		opt.cb.RecordFailure()
		logWarning("AI Plan generation failed, falling back to CBO", err)
	}

	// 降级路径：执行传统 CBO 计算
	return opt.fallbackCBO(sql)
}

func (opt *QueryOptimizer) tryAIInference(parentCtx context.Context, sql string) (*PhysicalPlan, error) {
	ctx, cancel := context.WithTimeout(parentCtx, opt.aiTimeout)
	defer cancel()

	ch := make(chan *PhysicalPlan, 1)
	errCh := make(chan error, 1)

	go func() {
		// 模拟 AI 推理过程
		plan, err := mockNeuralInference(sql)
		if err != nil {
			errCh <- err
			return
		}
		ch <- plan
	}()

	select {
	case <-ctx.Done():
		return nil, ErrInferenceTimeout
	case err := <-errCh:
		return nil, err
	case plan := <-ch:
		return plan, nil
	}
}

func (opt *QueryOptimizer) validatePlan(plan *PhysicalPlan) bool {
	if plan == nil || math.IsNaN(plan.Cost) || math.IsInf(plan.Cost, 0) {
		return false
	}
	if plan.Cost > opt.maxCostLimit || len(plan.Operators) == 0 {
		return false
	}
	return true
}

func (opt *QueryOptimizer) fallbackCBO(sql string) (*PhysicalPlan, error) {
	// 确定的传统启发式与代价估计逻辑
	return &PhysicalPlan{
		PlanID:    "cbo_fallback_plan",
		Cost:      120.5,
		IsAIBased: false,
		Operators: []string{"IndexScan", "HashJoin"},
	}, nil
}

func mockNeuralInference(sql string) (*PhysicalPlan, error) {
	// 此处模拟推理耗时与模型结果输出
	time.Sleep(3 * time.Millisecond)
	return &PhysicalPlan{
		PlanID:    "ai_plan_v1",
		Cost:      45.2,
		IsAIBased: true,
		Operators: []string{"VectorizedIndexScan", "ParallelHashJoin"},
	}, nil
}

func logWarning(msg string, err error) {
	fmt.Printf("[OPTIMIZER_WARNING] %s: %v\n", msg, err)
}

示例把超时和失败留在模型分支中处理。context.WithTimeout 约束等待时间；连续失败达到阈值后，熔断器暂时跳过模型分支。实际实现还需补上冷却期、半开探测和任务取消是否真正生效的观测。

---

4. 降级方案决策矩阵 (Trade-offs)

在设计降级机制时，不能简单采用“一刀切”的完全关闭策略。以下为三类生产常用降级方案的对比：

下表用于比较方案边界，不代表通用性能结论。延迟、资源占用和超时阈值应在目标数据库版本、数据分布与并发模型下分别测量。

降级模式	响应延迟 (P99)	CPU / 内存消耗	计划优化质量	适用场景
硬超时同步降级	取决于超时预算	较低	回退传统 CBO	延迟预算严格的在线查询
影子验证	会增加额外计算	较高	可对比两类计划	模型上线前的离线或小流量校验
启发式规则修正	较低	较低	处理已知异常算子	已明确异常边界的分析查询

在线业务可从“短超时 + 熔断 + CBO 回退”开始。模型调用占用多少预算，应结合最短查询、尾延迟目标和模型队列情况测出来，而不是套用固定比例。

---

5. 关键监控指标与验证基准

验证 AI 降级机制是否在生产生效，需监控以下 Prometheus 指标：

1. db_optimizer_ai_inference_duration_seconds：AI 推理耗时直方图，检查 P95/P99 是否触及超时阈值。
2. db_optimizer_fallback_total{reason="timeout|validation_failed|circuit_open"}：降级计数器，按原因分类统计。
3. db_executor_query_latency_seconds{plan_type="ai|cbo"}：对比 AI 计划与降级 CBO 计划的执行耗时差异。

压测时可以人为延迟推理服务，观察以下事件顺序是否符合设计：

[Fault Injection: inference delay]
T+0   : 推理耗时上升，记录推理直方图。
T+超时: 调度器走 CBO，并增加按原因区分的回退计数。
T+阈值: 熔断器打开，后续请求跳过模型分支。
恢复后: 通过半开探测确认模型恢复，再逐步恢复调用。

把模型限制为候选计划来源，并把回退、指标和演练做完整，才能判断它是否适合进入实际流量。