1. 课程导入与优化工程全景

很多团队把 SQL 优化理解为“把慢 SQL 改快”，于是出现一种典型场景：某条语句今天从 8 秒降到 0.2 秒，下周数据量增长或统计信息刷新后，又变成 6 秒，甚至比原来更慢。问题不在于某次改写不够聪明，而在于缺少工程化视角——没有把 SQL 语句、执行计划、统计信息和优化器当作一个持续运转的系统来管理。本课程要建立的，正是这种从“问题 SQL”到“稳定执行计划”的工程化思维。

优化工程的目标不是“快一次”，而是“稳得住”

Oracle SQL 优化工程的目标可以拆成三层。第一层是正确性：结果集必须与业务语义一致，任何以牺牲正确性换取的性能提升都不可接受。第二层是可预期的性能：在给定数据规模、并发量和硬件条件下，关键 SQL 的响应时间与资源消耗落在可接受区间内，而不是随机波动。第三层是稳定性：当数据分布变化、统计信息更新、索引增删或参数调整时，执行计划不会突然劣化，或者即使劣化也能被快速发现和回退。

这三层目标决定了优化不是一次性动作，而是一条闭环链路：发现问题 SQL → 采集执行计划与统计信息 → 定位根因 → 实施干预 → 验证效果 → 纳入监控与回归。缺少任何一环，优化成果都可能只是暂时的。

四个核心对象构成优化工程的基本盘

理解优化工程，先要理解四个核心对象及其相互关系。

• SQL 语句：业务意图的载体，也是优化工程的输入。同一条语义可以用不同写法表达，而不同写法会直接影响优化器的估算与选择。
• 执行计划：优化器为 SQL 选定的访问路径与连接方式的组合，是性能的直接决定因素。它描述“怎么取数”，而不是“取什么数”。
• 统计信息：描述表、列、索引的数据分布特征，是优化器估算代价的基础。统计信息失真，执行计划就可能偏离真实最优。
• 优化器：基于 SQL 语义、统计信息和系统参数，通过代价模型选择执行计划的组件。它既是决策者，也是被统计信息质量直接影响的对象。

四者关系可以概括为：SQL 语句提供语义，统计信息提供数据画像，优化器据此生成执行计划，执行计划决定实际性能。任何一环出问题，最终都会体现在执行计划上。

角色分工：DBA、开发与业务的三方协作

优化工程不是 DBA 一个人的事。开发人员最了解 SQL 的业务语义与数据访问模式，负责 SQL 写法、绑定变量使用和索引需求提出；DBA 掌握数据库运行状态、统计信息策略、执行计划基线和资源管理，负责诊断与干预；业务方则提供数据增长预期、峰值时段和可接受的响应时间标准。三方信息不对称，是很多优化反复失败的根源。

一个常见的协作断点是：开发只提交“这条 SQL 慢”，DBA 只回复“加个索引试试”。正确做法是开发提供 SQL_ID、执行频次、典型绑定值、期望响应时间；DBA 返回执行计划关键算子、实际行数与估算行数偏差、等待事件分布。信息对齐后，优化才从猜测变成定位。

从问题 SQL 到稳定执行计划的工程化路径

下面给出一份可直接用于日常优化的检查清单，字段和判断依据都围绕 Oracle 实际可观测对象设计。

以一条典型语句为例：SELECT * FROM orders WHERE customer_id = :cid AND status = 'PAID'。若执行计划显示全表扫描且 A-Rows 远小于 E-Rows，说明优化器低估了过滤性。此时先查 customer_id 与 status 的统计信息和直方图，再判断是补组合索引、收集统计信息，还是用 SQL Plan Baseline 固定已验证计划。每一步都要有可观测的输入与输出，而不是凭经验“试一下”。

建立工程化思维的关键转变

从“调 SQL”转向“管计划”，需要完成三个转变。第一，从关注单条语句转向关注 SQL 集合与执行频次，优先处理累计消耗最高的语句。第二，从依赖经验转向依赖证据，用执行计划、实际行数、等待事件说话。第三，从一次性修复转向持续监控，把关键 SQL 的执行计划纳入基线管理，让性能可预期、可回归、可追溯。

本课程后续将围绕这四个核心对象逐层展开：如何读懂执行计划、如何判断统计信息质量、如何理解优化器代价选择、如何用 SQL Plan Management 稳定计划，以及如何在真实业务场景中完成从诊断到验证的完整闭环。掌握这条主线，你面对的不再是一条条孤立的慢 SQL，而是一套可复用的优化工程方法。