Oracle 12c/19c 自适应查询优化框架:这确实是 CBO 演进中的一个里程碑，从“一次性编译”转向“持续学习优化”的模式。

核心范式转变：从“编译时优化”到“运行时自适应 + 迭代学习”

划分的 Adaptive Plan 和 Adaptive Statistics 两条主线，恰恰对应了优化器应对不确定性（数据分布未知、绑定变量窥探偏差等）的两种策略和时间点：

1. 运行时即时修正 ：当计划本身有备选方案时，在 本次执行中 实时切换。

2. 执行后学习反馈 ：当计划本身无法切换时，记录教训，用于 下一次硬解析 。

对您梳理内容的深度解读与补充

一、Adaptive Plan：动态修正的艺术

这相当于为执行计划安装了“ 传感器 ”和“ 备用变速箱 ”。

• Statistics Collector ：是关键“传感器”，在管道执行计划中暂存中间结果行数，为决策提供实时数据。

• 核心价值 ：解决因 绑定变量窥探 、 初次解析时统计信息缺失 等导致的严重计划错误，避免一次错误的硬解析就导致长时间的性能灾难。

• 参数拆分的意义 ： optimizer_adaptive_plans=TRUE 是相对“安全”的，因为它只影响当前执行，且切换逻辑清晰。而 optimizer_adaptive_statistics=FALSE （默认）则是因为其触发的后台动作（如SPD）可能带来额外的系统开销和复杂性，需要DBA有选择地开启。

二、Adaptive Statistics：优化器的“记忆”与“学习系统”

这是一套 跨SQL执行的生命周期学习机制 。

• 工作流程闭环 ：

  1. 发现问题 ：某SQL执行时，优化器发现估算严重偏离实际（Cardinality Feedback）。

  2. 记录线索 ：将问题根源（如：列关联、倾斜）记录为 SQL Plan Directives 。

  3. 分析改进 ：后台自动统计信息收集任务 ( DBMS_STATS ) 看到SPD后，会针对性创建 扩展统计信息 或更精准的 直方图 。

  4. 应用成果 ：下次该SQL硬解析时，CBO使用更准确的统计信息，生成更好的计划。

  5. 验证迭代 （19c）：如果新统计信息下估算仍不准，会触发“二次反馈”，形成学习循环。

• SPD的关键角色 ：它是连接“ 一次性执行反馈 ”和“ 持久化统计信息 ”的桥梁。它将针对单个SQL的优化经验，沉淀为可被所有SQL共享的、更基础的数据特征描述。

三、19c 的增强：走向成熟与智能化

19c 的改进表明该技术已进入“ 精细化运营 ”阶段：

• 更智能的决策 ：细化切换阈值，避免在计划边界摇摆不定。

• 更长的记忆 ：延长SPD生命周期，服务于长周期报表和数据分析负载。

• 更深度的集成 ：与 Exadata 智能存储、向量化执行等底层硬件/软件特性结合，释放更大性能潜力。

总结与最佳实践视角

我们可以更进一步概括：

• 12c 奠基 ：引入了“ 动态计划 ”与“ 反馈学习 ”两大支柱，让优化器活了起来。

• 19c 深化 ：优化了自适应机制的 稳定性 、 持久性 和 智能化 程度，并与现代硬件架构深度集成。

对DBA和开发者的启示：

1. 理解默认设置 ：Oracle 默认开启 Adaptive Plan，关闭 Adaptive Statistics，是平衡性能收益与管理复杂性的审慎选择。生产环境开启 optimizer_adaptive_statistics 前需充分测试。

2. 监控新动态 ：

   • 查看 V$SQL 中的 IS_REOPTIMIZABLE 字段。

   • 监控 DBMS_SPD 包相关视图，了解SPD的产生和消费情况。

   • 观察执行计划中的 Adaptive 关键字和 Statistics Collector 操作。

3. 问题诊断 ：当出现性能波动时，自适应优化可能是“帮手”也可能是“帮凶”。需要将其纳入排查范围，例如，检查是否因频繁的自适应切换导致计划不稳定。

总而言之， Reoptimization 家族的核心思想是赋予CBO“实事求是”和“与时俱进”的能力 ，通过“实时调整”和“事后学习”两条腿走路，显著提升了复杂、多变负载下的数据库整体性能稳健性。这是一个从“静态蓝图”到“动态导航”的深刻变革。