======================================
ORACLE SQL性能调整快速指南
第一章 ORACLE SQL性能调整快速指南
第一节 简介
第二节 SQL语句优化
第三节 基于规则优化存在的问题及解决方法
第四节 基于代价优化存在的问题及解决方法
第五节 基于规则及代价优化存在的问题及解决方法
第六节 简单有效的SQL优化技巧
第七节 使用SQL提示语
第八节 使用DBMS_STATS来管理状态
第九节 对高频率的执行计划使用Outlines
第一节 简介
本书是一本ORACLE SQL优化的快速指南，它并不覆盖ORACLE优化的方方面面。
一堆废话，跳过了！
1.1.4 ORACLE 9I新特性
拿到ORACLE的新版本总是一件激动人心的事情。这一节主要列出ORACLE 9I新特性的一部分，这一部分新特性能帮助我们在SQL性能方面比以前取得更大的提高。下面来逐条说明：
* 一个新的INIT.ORA参数，FIRST_ROWS_n，在一个OLTP的系统中，此参数使基于代价的优化能够在确定最优的执行路径时做出更合理的选择。参数中的n可以等于1，10，100或是1000。假如设置参数为FIRST_ROW_1，数据库将选择最优的执行路径来返回一行数据，FIRST_ROW_10将选择最优的执行路径来返回十行数据；并以此类推。
* 对CURSOR_SHARING参数，新增了一个选项SIMILAR，使用共享游标的好处包括减少内存消耗，更快的解析速度和减少了latch的竞争。SIMILAR选项改变文本为绑定变量。但与FORCE不同的是，相似的语句能够使用同一块SQL区域，但不会影响已经被降级了SQL语句的执行路径。
* 新增了一个提示语叫CURSOR_SHARING_EXACT，这个参数使除了使用此参数以外的其它语句使用共享游标。也就是说，此提示语对单一的语句关闭共享游标特性。
* 在ORACLE 9I中的重大改进是避免了倾斜问题的产生。倾斜问题的产生是因为绑定变量的值是在执行路径确定后才被确定。假如在一张表中，存在一百万行记录的STATUS列的值为‘C’，表示关闭，而存在100行记录的STATUS列的值为‘O’，表示开放。当查询条件中有STATUS='O'时，ORACLE将使用STATUS列上的索引，而当查询条件中STATUS='C'时，ORACLE将进行一次全表扫描。而在ORACLE 9I之前的版本中，ORACLE会假定这两种状态的值所占比例为50比50，并且在两种情况下都将采用全表扫描。ORACLE 9I在确定执行路径前就决定了绑定变量的值，问题由此得到解决。
* 能够用ALTER INDEX MONITOR USAGE命令来找出那些没有用处的索引。
* 可以用DBMS_STATS去收集系统状态，包括一个系统的CPU和I/O使用情况。你能够发现哪一块磁盘是瓶颈，并且ORACLE会根据这些信息来调整执行路径。
* 新增了提示语，包括NL_AJ，NL_SJ，FACT，NO_FACT，以及FIRST_ROWS（n）。所有这些参数的细节会在第七节中进行详细描述。
* ORACLE 8I中新增的大纲功能使你能够对于特定的SQL语句使用特定的执行计划。但是，强制一个SQL语句使用特定的执行路径还不够灵活。ORACLE 9I在这方面提供了几乎无限的选择，现在可以用DBMS_OUTLN_EDIT来编辑大纲。
PART 2
第二节 SQL优化器
当你执行一个SQL语句时，一个被称为优化器的数据库的部件会决定对于这句SQL来说最佳的方式来访问数据。ORACLE数据库支持两种优化器，基于规则的优化（这种方式是缺省的）和基于代价的优化。
为了发现对于一句SQL来说最佳的执行数据径，优化器考虑以下因素：
* SQL语句所采用的语法
* 数据必须符合所有条件（WHERE子句）
* 语句所需要访问的数据库表。
* 在由表中获得数据时所有可能用到的索引。
* ORACLE 关系型数据库存管理系统的版本。
* 正确的优化模式。
* SQL语句中的提示语
* 所有存在的对象状态信息（通过ANALYZE命令来产生）
* 数据表的物理定位（分布式SQL）
* INIT.ORA的设定（并行查询，同步IO等等）
ORACLE提供了二者必居其一的两种优化方式：行为可以被预测的基于规则的优化和更加智能化的基于代价的优化。
1.2.1 理解基于规则的优化
基于规则的优化使用一套预先定义好的优先规则来找出用来访问数据库的方式。关系型数据库管理系统在下面这些情况时会缺省使用基于规则的优化器：
INIT.ORA文件中的指定了OPTIMIZER_MODE=RULE
指定了OPTIMIZER_MODE=CHOOSE并且语句中所涉及到的所有表都没有可用的状态信息。
ALTER SESSION SET OPTIMIZER_MODE=RULE命令被使用。
ALTER SESSION SET OPTIMIZER_MODE=CHOOSE命令被使用，并且语句所涉及的所有表都没有可用的状态信息。
在语句中使用了规则提示语（如SELECT /*+RULE*/...）
基于规则的优化器主要受20种有优先级的规则所控制，这些规则告诉优化器如何决定一条语句的执行路径，什么时候选择某一个索引还不是另一个，什么时候应该进行全表扫描。这些规则，被列出在表1-1中，它们是固定的，可以预先确定的，相对于基于代价的优化器来说，不会被外部的条件所影响（如表的大小，索引的分布等）
表1-1.基于规则的优化器的
1 ROWID等于常量
2 唯一键值或主键的聚簇连接
3 唯一键值或主键的哈希聚簇连接
4 整个复合索引等于常量
5 唯一索引列等于常量
6 完全聚簇键等于同一个聚簇上的另一个表对应的聚簇键
7 哈希聚簇键等于常数
8 完全聚簇键等于 常数
9 整个非唯一组合索引等于常量
10 非唯一索引连结
11 整个组合索引等于小范围的值
12 组合索引的大部分前面的列等于常量
13 索引列取值存在上限和下限或者索引列LIKE ABC%（范围限制）
14 非唯一索引列取值存在上限和下限或者索引列LIKE ABC%（范围限制）
15 唯一索引列或是常量（范围无限制）
16 非唯一索引列或是常（范围无限制）
17 Equality on non-indexed = column or constant (sort/merge join)[这一句实在是不知道怎么翻译，请大家指点！]
18 单一索引列的最大或最小值
19 ORDER BY整个索引
20 全表扫描