学习型优化器上线后怎样观察查询结果学习型优化器上线后观察重点是它是否改善了端到端查询而不是模型的单项耗时。推理、计划缓存、传统优化器和执行器共享同一条请求链只要其中一环排队短查询的体验就可能变差。观测点要覆盖决策与结果建议按 SQL 指纹和计划版本记录模型调用耗时、队列等待、是否回退、估算行数与实际行数的偏差、计划缓存命中以及端到端分位延迟。原始 SQL、参数、业务字段和完整特征向量不应进入普通日志需要排查时使用脱敏样本和受控采样。阈值没有统一答案。以当前 CBO 基线和代表性负载建立分布再设定告警与回退门槛。回退次数增多不必然说明模型错误也可能是容量保护在生效结合队列和资源指标才能判断。代码中的最小观测边界type Decision struct { UseAI bool; Reason string } func recordDecision(d Decision, inference time.Duration) { // 记录聚合指标路径、原因和耗时不要记录原始 SQL 或用户参数。 _ d _ inference }追踪 span 可用于关联优化与执行阶段但要限制属性数量和基数。模型置信度也不应单独作为“正确性”证明它需要和后续执行反馈、影子比对一起评估。闭环要能停下来对异常计划保存可复现的脱敏输入、模型版本、统计信息版本和计划摘要。先在影子环境复现再决定调整模型、统计信息或准入阈值。模型路径必须能够独立关闭关闭后仍由已有 CBO 正常提供服务。