通过分析SQL语句的执行计划优化SQL(三)
四：ORACLE的优化器
优化器有时也被称为查询优化器，这是因为查询是影响数据库性能最主要的部分，不要以为只有SELECT语句是查询。实际上，带有任何WHERE条件的DML(INSERT、UPDATE、DELETE)语句中都包含查询要求，在后面的文章中，当说到查询时，不一定只是指SELECT语句，也有可能指DML语句中的查询部分。优化器是所有关系数据库引擎中的最神秘、最富挑战性的部件之一，从性能的角度看也是最重要的部分，它性能的高低直接关系到数据库性能的好坏。
我们知道，SQL语句同其它语言(如C语言)的语句不一样，它是非过程化(non-procedural)的语句，即当你要取数据时，不需要告诉数据库通过何种途径去取数据，如到底是通过索引取数据，还是应该将表中的每行数据都取出来，然后再通过一一比较的方式取数据(即全表扫描)，这是由数据库的优化器决定的，这就是非过程化的含义，也就是说，如何取数据是由优化器决定，而不是应用开发者通过编程决定。在处理SQL的SELECT、UPDATE、INSERT或DELETE语句时，Oracle 必须访问语句所涉及的数据，Oracle的优化器部分用来决定访问数据的有效路径，使得语句执行所需的I/O和处理时间最小。
为了实现一个查询，内核必须为每个查询定制一个查询策略，或为取出符合条件的数据生成一个执行计划(execution plan)。典型的，对于同一个查询，可能有几个执行计划都符合要求，都能得到符合条件的数据。例如，参与连接的表可以有多种不同的连接方法，这取决于连接条件和优化器采用的连接方法。为了在多个执行计划中选择最优的执行计划，优化器必须使用一些实际的指标来衡量每个执行计划使用的资源(I/0次数、CPU等)，这些资源也就是我们所说的代价(cost)。如果一个执行计划使用的资源多，我们就说使用执行计划的代价大。以执行计划的代价大小作为衡量标准，优化器选择代价最小的执行计划作为真正执行该查询的执行计划，并抛弃其它的执行计划。
在ORACLE的发展过程中，一共开发过2种类型的优化器：基于规则的优化器和基于代价的优化器。这2种优化器的不同之处关键在于：取得代价的方法与衡量代价的大小不同。现对每种优化器做一下简单的介绍：
基于规则的优化器 -- Rule Based (Heuristic) Optimization(简称RBO)：
在ORACLE7之前，主要是使用基于规则的优化器。ORACLE在基于规则的优化器中采用启发式的方法(Heuristic Approach)或规则(Rules)来生成执行计划。例如，如果一个查询的where条件(where clause)包含一个谓词(predicat
相关文档：
1、SELECT 查询语句和条件语句
SELECT 查询字段 from 表名 WHERE 条件
查询字段：可以使用通配符* 、字段名、字段别名
表名： 数据库.表名 ，表名
常用条件： = 等于 、<>不等于、in 包含 、 not in 不包含、 like 匹配
BETWEEN 在范围 、 not BETWEE ......
表如下
一条语句显示所有大于25岁和下的人，以上的人显'大龄'
select case when age>25 then '大龄' else '小龄' end as 年龄级别,count(*) as 人数 from infor group by case when age>25 then '大龄' else '小龄' end
......
在数据库的日常维护中，调整个别性能较差的SQL语句是一项极富挑战性的工作。其中的关键在于如何得到SQL语句的执行计划和如何从SQL语句的执行计划中发现问题。总是想将日常经验的点点滴滴总结一下，但是直到最近才下定决心，总共花了3个周末时间，才将其整理成册，便于自己日常工作。现在将其发表出来希望能与更多的朋友分 ......
在Win7下安装SQL2005开发版，安装SQL Native Client时提示安装中断，没有在意，然后在安装SQL Server时又提示“[Microsoft][SQL Native Client]客户端不支持加密.SQL Server 安装程序无法连接到数据库服务进行服务器配置.”卸载SQL Native Client重新安装，还是中断，修复，也中断，再卸载，清理注册表，重� ......
