自动化查询优化评测：平均耗时下降不代表可以上线
自动化查询优化评测：平均耗时下降不代表可以上线
一、数据库优化最怕平均值掩盖尾部风险
智能查询优化模型上线前，必须经过严格评测。很多实验报告只展示平均查询耗时下降，但数据库系统更关心稳定性和最坏情况。一个优化器如果让 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 关联上下游调用。这样排查问题时不用靠猜，也能区分是代码逻辑、外部依赖还是容量配置导致的故障。
五、总结
智能查询优化评测不能只看平均耗时下降。延迟分布、最坏情况、计划稳定性、资源消耗和回退能力，才是判断数据库内核智能化能否上线的关键指标。
