智能查询计划灰度发布先验证什么把模型接到优化器前先不要急着看它能不能跑出更快的计划。灰度阶段真正要回答的是它在什么查询上可靠失效时是否能退回已有优化器以及观测本身会不会干扰主业务。先做影子评估再放小流量影子评估适合比较计划不适合默认完整重放所有查询。对写语句、含敏感参数的语句和资源成本过高的查询应只记录脱敏后的结构特征或在隔离数据集重放。主请求仍由现有 CBO 执行模型只产出候选计划、预估代价和置信信息。影子任务应设置独立队列、并发上限和取消条件。不要假定它一定“低优先级”就没有影响读放大会挤占缓存重放也可能放大 I/O。资源配额应由压测确定并持续观察主路径的队列长度、缓存命中和尾延迟。指标要能解释决策基数误差可以用 Q-error 描述$$Q \max(\hat y/y, y/\hat y)$$但它只是诊断信号。应按查询模板、数据版本和参数范围分别统计并与最终耗时、扫描行数、内存峰值一起看。一个估计误差较大的计划未必慢反过来模型推理或计划编译的额外时间也可能抵消收益。建议为每次候选计划记录模板标识、统计信息版本、候选与基线计划摘要、估算值、实际执行指标、拒绝或回退原因。这样模型更新后才能定位差异而不是只看到总体平均值。小流量执行前的门槛进入小流量前候选计划至少要通过语义等价校验、权限校验和资源上限检查。对模型超时、特征缺失、Schema 变化、估计越界等情况直接选择基线计划。回退路径应是同步且简单的不依赖另一套远程服务。阈值不要写死成通用数字。可以从单一模板和只读查询开始在固定数据快照上做回放再逐步扩大范围。每一步都保留停用开关和模型版本回滚记录。验证清单结果集或可比较摘要是否与基线一致。模型和影子任务是否影响主路径的 p95/p99、缓存和队列。Schema、统计信息或数据分布变化后拒绝率和回退率是否可解释。模型不可用时系统是否仍能只靠既有优化器完成请求。灰度不是为模型找一组漂亮数字而是确定它的边界。边界明确后才值得讨论扩大流量。