打开SQL性能的“黑匣子”：深入Oracle优化器内核与CBO决策之道

阅读时间： 2025年07月23日
章节： 1.1 什么是Oracle里面的优化器
摘要： 本章节是全书的基石，它定义了我们工作的核心舞台——优化器。理解其工作模式，特别是从基于规则到基于成本的演进，是我们进行一切SQL性能诊断和优化的逻辑起点。

一、核心概要

本章节的核心，是阐述了Oracle两种截然不同的SQL优化哲学：基于规则和基于成本。

• • 基于规则的优化器(RBO)：一个遵循硬编码规则集的“老古董”。它的行为完全可预测，但极其僵化，无法适应复杂的数据环境。在10g后，它已成为历史，我们现在了解它，更多是为了处理极少数的遗留系统，或是理解某些历史设计决策的背景。
• • 基于成本的优化器(CBO)：现代Oracle的心脏。它是一个复杂的成本计算引擎，通过分析表的统计信息（数据量、分布、关联性等），估算不同执行路径的“成本”（一个代表资源消耗的加权值），并选择成本最低的那个。我们99.9%的SQL优化工作，都是在与基于成本的优化器打交道。

二、关键概念重述与实战解读

对于我们DBA来说，理解基于成本的优化器的“语言”至关重要。本章节提到的几个概念，就是其决策的核心词汇：

1. 1. 集的势
• • 是什么： 优化器对某一步操作后，返回结果集的行数估算。
• • 实战解读： 这是我们阅读执行计划时，必须关注的第一指标。执行计划里的 Rows
   列就是它。当这个估算值与实际情况出现数量级上的偏差时（比如优化器估算10行，实际返回100万行），几乎可以断定，优化器做出了错误的决策，后续的表连接方式、索引选择等一系列判断都将是错误的。发现并纠正错误的基数估算，是SQL优化的关键突破口。
2. 2. 可选择率
• • 是什么： 描述一个查询谓词（WHERE条件）能从总行数中过滤出多少比例的数据。公式为 选择率 = 基数 / 总行数
  。
• • 实战解读： 选择率是优化器计算基数的“系数”。一个高选择性的谓词（如 WHERE unique_key = 'value'
  ）能让优化器非常有信心地估算出小基数，从而倾向于使用索引。而一个低选择性的谓词（如 WHERE non_indexed_col LIKE '%value%'
  ），优化器会认为将返回大量数据，可能直接选择全表扫描。我们在设计索引时，实质上就是在为关键查询的谓词提供高选择性的访问路径。
3. 3. 可传递性
• • 是什么： 优化器的推理能力。当存在 t1.colA = t2.colB
   和 t1.colA = 10
   时，优化器能自动推导出 t2.colB = 10
   的结论。
• • 实战解读： 这个特性被称为“谓词推移”，它非常强大。它允许优化器将一个表的过滤条件“传递”给另一个表，以便在表连接之前就尽可能地减少结果集。这在多表JOIN的场景中能极大地提升性能。但同时，它也意味着SQL的执行计划可能因看似无关的改动而变化，增加了排查的复杂性。理解这一点，有助于我们分析那些“意想不到”的执行计划变更。

三、DBA的价值与常见陷阱

1. 1. 优化器的局限性 -> DBA的价值所在
   基于成本的优化器的软肋，也是我们DBA价值的核心体现：它完全依赖于统计信息。优化器本身是一个没有业务知识的、纯粹的计算引擎。我们的价值在于：
• • 确保输入数据的质量： 建立和维护精准、及时的统计信息收集策略。这是最基础，也是最重要的工作。
• • 解读和校准模型： 当优化器的模型失真时（例如对复杂函数、数据倾斜等场景估算不准），我们需要介入。通过扩展统计信息、SQL Profile、SQL Patch或在万不得已时使用Hint
  ，来“校准”优化器的认知。我们扮演的是优化器的“高级顾问”角色。
2. 2. 面向DBA的常见陷阱
• • 陷阱一：将统计信息视为“一劳永逸”的工作。 对于数据量、数据分布频繁变化的表，陈旧的统计信息比没有统计信息更危险，因为它会误导优化器做出极其糟糕的决策。
• • 陷阱二：看到全表扫描就认为是性能问题。 对于小表或者需要访问大部分数据的查询，全表扫描往往是成本最低、最高效的选择。我们的目标是“最低成本”，而不是“必须用索引”。
• • 陷阱三：过早或过度依赖Hint
  。 Hint
  是绕过优化器的“强制指令”，应作为最后手段。滥用Hint
  会使SQL失去对数据变化的适应性，造成长期的维护噩梦。优先考虑通过优化数据模型、索引和统计信息来“引导”优化器，是更专业的做法。