ORACLE优化器和执行计划的优化策略

Oracle在执行SQL语句前会分析执行计划。优化器负责此任务，并有两种优化方法： 基于规则（RBO）：优化器根据预设规则分析语句，例如使用有索引的列来获取索引。 基于代价（CBO）：优化器评估代价（CPU和内存），并在判断是否使用此方法时参考表和索引统计信息。 Oracle建议在8及更高版本中使用CBO。Oracle10g已取消对RBO的支持。

在ORACLE数据库中，执行计划的选择是关键优化点。所有可能的执行计划形成一个树型结构，通过有效遍历可以估算出最优的执行计划。通常由于时间限制，不可能遍历所有可能性，因此可能会选择出不正确的执行计划。

在Oracle数据库中，优化器的选择直接影响着SQL语句的执行效率。对于需要快速响应用户请求的操作，例如查询少量数据，可以选择first_rows作为优化目标。 然而，某些操作需要来自子步骤的所有行才能执行，例如排序、合并连接、分组和计算总计等。对于这类操作，all_rows作为优化目标可以最大程度地减少资源消耗。 实际执行过程中，SQL语句的步骤并不总是按顺序执行，而是可能并行处理以提高效率。例如，步骤3、5、4可以同时运行。 传统的树形执行计划难以清晰地展现步骤的执行顺序，而Oracle提供的另一种执行计划能够明确地显示每个操作的先后顺序，这对于理解和优化SQL语句至关重要。

在进行数据库管理时，理解ORACLE的执行计划和使用SQL优化技巧是至关重要的。通过深入研究执行计划，可以有效提高数据库查询性能。

优化器模式 基于规则的模式 (Rule 模式)：根据数据字典生成执行计划，是最旧且最稳定的模式。 选择模式 (Choose 模式)：默认模式，根据统计信息的可用性决定使用哪种优化器模式。 基于成本的第一行模式 (First_rows 模式)：优先快速返回记录。 基于成本的全部行模式 (All_rows 模式)：优化总体执行时间和资源消耗。

通过深入研究Oracle执行计划，可以显著提升您的SQL技能水平，从而大幅增强执行效率。技术进步的推动使得这一过程成为可能。

内部子查询中，当记录较少时，非关联子查询比关联子查询执行更快。关联子查询中使用in子句是多余的，而非关联子查询使用exists子句则不恰当。可以将非关联子查询中的in子句转换为标准连接操作，并使用select distinct去除重复记录；关联子查询中的exists子句可转换为标准连接，但子查询最好只返回一个记录。

Oracle数据库在执行SQL语句前，会先分析语句并制定执行计划。此分析工作由优化器负责，它提供两种优化方式：基于规则的优化（RBO）和基于代价的优化（CBO）。 RBO RBO遵循Oracle预设的规则进行SQL语句分析。例如，当WHERE子句中的列存在索引时，RBO会优先选择使用索引。 CBO CBO则关注语句执行的代价，主要指CPU和内存消耗。它参考表和索引的统计信息来判断是否采用CBO。值得注意的是，过期的统计信息可能导致CBO制定出错误的执行计划。 Oracle8及之后的版本推荐使用CBO，而Oracle10g已取消了对RBO的支持。

在ORACLE+SQL性能优化中，执行计划的步骤涉及从EMP表和SALGRADE表读取所有行（第３步和第６步）。第５步利用PK_DEPTNO索引查找第３步返回的每个DEPTNO值，并检索与DEPT表相关联的行的ROWID。第４步从DEPT表中检索出第５步返回的行。操作包括行源上的关联、排序和过滤等。第２步实现嵌套循环操作，连接第３步和第４步的行源，并将结果行返回到第１步。最终，第１步执行过滤操作，消除第２步中与第６步具有相应行的行，并返回剩余行给用户或应用。