AI 查询计划推荐：模型可以给候选，代价模型必须复核

数据库智能化里，查询计划推荐很诱人。模型看到 SQL、表结构、统计信息和历史执行数据，就给出 join 顺序、索引选择或算子策略。问题是，查询优化不是写建议书，错一个计划就可能把 p99 延迟打穿。AI 可以给候选计划，但代价模型必须复核。

真正可上线的智能优化器，不应该绕开数据库原有优化框架，而应该把模型输出纳入候选空间，再用可解释的代价、规则和保护阈值筛选。

一、模型输出只能是候选

flowchart TD
  A[SQL And Stats] --> B[AI Plan Candidate]
  A --> C[Rule Based Candidates]
  B --> D[Cost Model Review]
  C --> D
  D --> E[Safety Guard]
  E --> F[Final Plan]

如果模型直接决定最终计划，排障会很痛苦。执行慢了，你需要知道它为什么选这个 join 顺序、为什么放弃某个索引、为什么认为扫描更便宜。

二、输入特征要可验证

AI 推荐计划依赖特征，特征错了，输出再漂亮也没意义。

optimizer_features:
  table_rows: required
  column_ndv: required
  histogram: optional
  index_cardinality: required
  recent_runtime_stats: optional
  predicate_selectivity: required

统计信息过期时，模型也会被误导。建议把统计信息版本、采集时间和样本率写进推荐日志。

三、复核要看风险阈值

对于低风险查询，可以让 AI 候选更积极；对于核心交易查询，必须保守。可以设置计划切换阈值：只有候选计划预估收益足够大，且风险指标可控，才允许切换。

plan_guard:
  min_estimated_gain: 20%
  max_cardinality_error: 3x
  forbidden:
    - full_scan_on_large_table
    - nested_loop_without_index

这不是不信模型，是知道数据库事故不听解释。

四、上线要 shadow 观察

新计划不要直接接管生产流量。可以先 shadow 生成候选，记录如果采用它会选择什么，再与真实计划对比。

SELECT query_id, baseline_plan_hash, ai_plan_hash, estimated_cost, actual_latency
FROM plan_shadow_log
WHERE created_at >= now() - interval 1 day;

当候选计划长期稳定优于基线，再考虑灰度。灰度阶段还要支持快速回退到原计划。

灰度时不要只看平均耗时。要按 SQL 模板、参数区间、表数据量和租户维度拆开看。智能计划在常见参数上表现很好，不代表在极端参数上安全。尤其是数据倾斜明显的表，一个 plan 对大客户和小客户可能完全不是一回事。

plan_rollout_metrics:
  latency_p95_by_digest
  rows_examined_delta
  temp_table_count
  fallback_count
  plan_regression_samples

如果发现候选计划导致扫描行数放大，即使延迟暂时没涨，也应该暂停扩大流量。数据库事故往往先从代价指标失真开始。

五、总结

AI 查询计划推荐的正确位置，是扩展候选计划空间，而不是替代优化器拍板。模型可以提出候选，代价模型、规则保护和 shadow 观察必须复核。

数据库优化最怕自信的黑箱。智能化可以提高探索效率，但最终计划必须经得起统计信息、代价和生产证据的审问。

换句话说，AI 可以参与优化器，但不能成为不可解释的最终裁判。能回退、能复核、能复现，才有资格进入查询执行路径。