自动化查询优化评测平均耗时下降不代表可以上线一、数据库优化最怕平均值掩盖尾部风险智能查询优化模型上线前必须经过严格评测。很多实验报告只展示平均查询耗时下降但数据库系统更关心稳定性和最坏情况。一个优化器如果让 95% 查询快一点却让 1% 核心查询慢几十倍就不能上线。数据库优化的容错空间远小于普通推荐任务。评测集应覆盖多种 SQL 类型点查、范围扫描、聚合、排序、多表 join、子查询、复杂表达式和参数化查询。还要覆盖不同数据分布例如均匀分布、长尾分布、强相关列和数据倾斜。只在公开 benchmark 上跑分无法证明生产可用。二、评测链路传统计划和智能计划必须同场比较flowchart TD A[查询样本] -- B[传统优化器计划] A -- C[智能优化器计划] B -- D[执行指标采集] C -- D D -- E[延迟分布] D -- F[资源消耗] D -- G[错误与回退] E -- H[上线评估] F -- H G -- H指标至少包括平均延迟、P95/P99、最大耗时、扫描行数、内存占用、临时文件、计划变化率和回退次数。计划稳定性非常重要。同一类查询如果计划频繁抖动缓存命中和性能预期都会变差。三、上线判定实现最坏情况优先于平均收益下面是一个简单的评测结果判定逻辑。它体现了“最坏情况优先”的原则。def accept_optimizer(baseline, candidate): if candidate[errors] 0: return False if candidate[p99_ms] baseline[p99_ms] * 1.05: return False if candidate[max_ms] baseline[max_ms] * 1.2: return False if candidate[avg_ms] baseline[avg_ms] * 0.95: return True return False四、灰度与回退先 shadow再小流量执行灰度上线时可以采用 shadow 模式。线上仍执行传统优化器计划同时让智能优化器生成候选计划并记录对比不实际执行或只对低风险查询执行。等 shadow 数据证明稳定后再扩大范围。对于核心业务 SQL应支持计划绑定和快速回退。评测还要考虑统计信息变化。模型在某一天表现好不代表数据增长、分区变化和索引调整后仍然可靠。智能优化器需要持续监控发现候选计划风险升高时自动降级。还要保留人工审查入口。对于扫描行数异常、内存风险高或计划变化大的 SQL即使模型置信度高也应进入人工确认。智能优化的目标是减少人工负担不是取消数据库工程判断。评测结果还应分层展示。低风险短查询、复杂 join、核心报表和后台任务的上线阈值不应相同。对核心 SQL可以要求候选计划在多轮数据快照上都不退化对低风险查询则可以接受更激进的灰度。分层后智能优化器才不会被少数高风险场景完全绑住也不会把核心链路暴露给不成熟策略。评测集也需要定期刷新。业务新增字段、索引调整和数据增长都会改变计划空间旧样本会逐渐失真。把线上慢查询和回退案例持续纳入评测才能让模型能力跟上真实负载。生产落地补充从能跑到可维护从生产落地角度看这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束读者很难判断它能否放进真实系统。评估时建议先定义三类指标正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信稳定性指标回答失败时是否可控成本指标回答持续运行是否划算。三类指标要同时进入验收清单不能只用平均耗时或单次成功率证明方案有效。实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型指标至少覆盖成功率、超时率、重试次数和队列长度必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜也能区分是代码逻辑、外部依赖还是容量配置导致的故障。五、总结智能查询优化评测不能只看平均耗时下降。延迟分布、最坏情况、计划稳定性、资源消耗和回退能力才是判断数据库内核智能化能否上线的关键指标。