学习型查询优化器特征漂移比模型精度更麻烦一、优化器引入模型后问题不会自动变少学习型查询优化器希望用机器学习改进基数估计、代价预测或计划选择。方向本身有价值因为传统优化器在复杂谓词、相关列和数据倾斜场景下经常估错。但把模型引入优化器以后系统多了新的不确定性训练数据是否覆盖线上查询特征是否稳定数据分布是否漂移错误计划如何兜底。数据库优化器最重要的品质不是偶尔选择一个惊艳计划而是长期稳定地避免灾难计划。学习型组件如果不能被约束就可能在少数查询上带来巨大回退。优化器里不缺聪明缺的是可解释和可兜底。二、优化链路模型只能参与部分决策flowchart TD A[SQL 解析] -- B[逻辑计划] B -- C[候选物理计划] C -- D[特征抽取] D -- E[学习型代价模型] E -- F[计划选择] F -- G[执行反馈] G -- H[训练数据更新]学习型模型可以参与基数估计、成本修正或候选计划排序但不应该绕过规则约束。比如不满足索引条件的计划不能被强行选择内存超限的 hash join 不能只因为预测快就执行跨分片查询不能忽略网络成本。规则负责边界模型负责排序这是比较稳妥的分工。特征设计比模型选择更关键。表行数、列基数、直方图、谓词类型、join 图、索引覆盖、历史执行时间、缓存状态和并发负载都可能影响计划。但特征越多漂移和采集成本越高。工程上要选择稳定、低成本、可解释的特征。三、漂移检测计划回退要可观测下面是一个简化的执行反馈记录。它用于判断预测成本和实际耗时是否持续偏离。{ query_fingerprint: select_orders_by_user_status, chosen_plan: idx_user_status_range_scan, predicted_cost: 1820.5, actual_latency_ms: 93.4, actual_rows: 12890, estimated_rows: 420, feature_version: v7 }如果估算行数和实际行数长期偏离说明统计信息或模型特征存在问题。若某类 query fingerprint 的实际延迟持续高于预测就要触发模型降权或回退到传统优化器。学习型组件必须有自我怀疑能力否则它会把错误变成系统性问题。灰度也要按查询类型进行。不要把模型优化器一次性放到全部 SQL 上。可以从只读分析查询开始逐步扩展到复杂 join再考虑交易查询。每一类查询都要记录计划变化率、性能提升分布和性能回退分布。平均值漂亮没有用P99 回退会写进事故复盘。四、上线边界保护机制比模型结构更重要学习型优化器上线需要至少三层保护。第一层是计划白名单或黑名单避免选择已知危险计划。第二层是运行时资源限制例如内存、临时文件和执行时间。第三层是反馈回滚当实际执行明显偏离预测时降低模型权重或切回传统代价模型。还要处理冷启动。新表、新索引、新业务查询没有历史样本模型容易失准。冷启动阶段应更多依赖传统统计信息等积累足够执行反馈后再让模型参与。模型不是凭空知道新业务它只是在历史分布上做预测。最后解释能力不能省。DBA 或内核工程师需要知道模型为什么偏好某个计划。即使无法完全解释复杂模型也要输出关键特征、候选计划差异和预测置信度。优化器选错计划时排障人员不能对着一个黑盒发呆。五、总结学习型查询优化器的难点不只是模型精度更是特征稳定、分布漂移、错误兜底和可观测性。模型可以参与代价修正和计划排序但必须受规则保护。数据库优化追求稳定收益不追求不可解释的聪明。