AI 数据库内核优化：智能查询计划不能绕过代价模型
一、智能优化器不能脱离数据库的基本纪律
AI 进入数据库内核优化后，最常被讨论的是智能查询计划生成。模型可以根据 SQL、统计信息和历史执行记录预测更优计划，但它不能绕过数据库最基本的代价模型。查询优化器的核心问题，是在大量等价执行计划中选择成本最低的路径。AI 可以提供候选和修正，不能凭感觉替代可解释的成本估算。
传统优化器依赖表统计、基数估计、索引信息和算子代价。问题在于真实数据分布经常不符合假设，列相关性、数据倾斜、过期统计信息都会导致估算偏差。AI 的价值可以放在两个位置：一是修正基数估计，二是基于历史执行反馈选择更稳的计划。直接让模型输出完整执行计划，风险更高，因为错误计划可能放大到全表扫描、错误 join 顺序或内存溢出。
二、优化链路：AI 更适合修正基数估计
flowchart TD
A[SQL 输入] --> B[解析与逻辑计划]
B --> C[候选物理计划]
C --> D[传统代价模型]
C --> E[AI 基数修正]
D --> F[计划排序]
E --> F
F --> G[执行与反馈]
G --> E
智能优化器必须保留可回退机制。模型建议的计划应与传统优化器计划做对比，只有在置信度足够高、历史样本相似、资源风险可控时才采用。否则应回退到稳定计划。数据库不是推荐系统，错一次可能就是生产事故。
三、计划选择实现：候选计划必须受风险阈值约束
下面是一个简化的计划选择逻辑。真实数据库会复杂得多，但核心思想是让 AI 建议受约束。
def choose_plan(classic_plan, ai_plan, confidence, risk_score):
if classic_plan is None:
raise ValueError("classic plan is required")
if ai_plan is None:
return classic_plan
if confidence < 0.8:
return classic_plan
if risk_score > 0.3:
return classic_plan
if ai_plan.estimated_cost >= classic_plan.estimated_cost * 1.2:
return classic_plan
return ai_plan
四、上线边界：最坏情况比平均收益更重要
训练数据也要谨慎。历史执行记录包含 SQL、计划、耗时、扫描行数和资源消耗，但同一 SQL 在不同参数、不同数据版本、不同缓存状态下表现可能差异巨大。训练时必须记录上下文，否则模型学到的是噪声。对在线系统而言，还要避免把异常事故数据当作正常样本。
评估智能查询优化不能只看平均耗时下降。更重要的是 P95/P99 延迟、最坏情况、计划抖动频率和回退成功率。一个模型让多数查询快 5%，却偶尔让核心查询慢 100 倍，这种收益不值得。
还要支持计划绑定和黑名单。对于核心 SQL，若某个稳定计划已经经过生产验证，智能优化器不应随意替换；对于历史上造成事故的计划形态，也应明确禁止。数据库优化的首要目标是稳定，而不是追求每次都更激进。
监控也要落到计划粒度。上线后至少记录查询指纹、候选计划哈希、实际计划哈希、估算行数、实际行数、内存峰值和回退原因。只有这些指标长期可查，团队才能判断模型是在稳定修正估算，还是偶尔靠运气命中更优计划。对数据库内核来说，可观测性本身就是优化器能力的一部分。
生产落地补充：从能跑到可维护
从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。
评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。
五、总结
AI 数据库内核优化应作为代价模型和执行反馈的增强，而不是绕过传统优化器。智能查询计划必须可解释、可回退、可评估，并以最坏情况风险作为上线前提。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/guoyizhongxing/article/details/162496496
