开始学习崔老师的《基于Oracle的SQL优化》，七百多页，虽然可能会比较痛苦，但想必是一个痛并快乐的过程，尽情享受了。。。
第一章：Oracle里的优化器
优化器是Oracle数据库中内置的一个核心子系统，可以理解为一个核心模块或者一个核心功能组件。优化器的目的是按照一定的判断原则来得到它认为的目标SQL在当前情形下最搞笑的执行路径，也就是说，优化器的目的是为了得到目标SQL的执行计划。
RBO内置的等级1所对应的的执行路径就是"single row by rowid(通过rowid来访问单行数据)"。等级15所对应的的执行路径则是"full table scan(全表扫描)"。
等价改写目标SQL，以让RBO生效。
目标where条件中对NUMBER或DATE类型的列加上0(如果是VARCHAR2或CHAR类型，可以加上一个空字符，例如||'')，这样原先可以用索引的就不能用了。对于多表连接的，这种改变可以影响表连接的顺序，进而使用RBO情况下对目标SQL执行计划作调整。
若两条或两条以上的等级值相同的执行路径。RBO会依据目标SQL中所涉及的相关对象在数据字典缓存中的缓存顺序和目标SQL中所涉及的各个对象在目标SQL文本中出现的先后顺序来综合的判断。这就意味着可以通过调整相关对象在数据字典缓存中的缓存中的顺序，改变目标SQL中所涉及的各个对象在该SQL文本中出现的先后顺序来调整其执行计划。
RBO的缺点：
靠硬编码在Oracle数据库代码库中的一些列固定的规则来决定目标SQL的执行计划，并未考虑SQL中所涉及的对象的实际数据量、实际数据分布等情况，一旦固定的规则不适用于该SQL中所涉及的实际对象时，RBO根据固定规则产生的执行计划就很可能不是当前情况下的最优执行计划了。
CBO：
Oracle自动计算执行路径的成本，直到目标SQL的各个可能的执行路径全部计算完毕或已达到预先定义好的待计算的执行路径数量的阈值。
集的势：
Cardinality，指指定集合所包含的记录数。即指定结果集的行数。表示对目标SQL的某个具体执行步骤的执行结果所包含的记录数的估算。当然，如果是针对整个目标SQL，那么此时的Cardinality就表示对该SQL最终执行结果所包含的记录数的估算。某个执行步骤的对应Cardinality值越大，那么所对应的成本值往往也就越大，这个执行步骤所在执行路径的总成本值也就会越大。
可选择率：
Selectivity，指施加指定谓词条件后返回结果集的记录数占未施加任何谓词条件的原始结果集的记录数的比率。
可选择率的值越大，就意味着返回结果集的Cardinality的值就越大，所以估算出来的成本值也就会越大。
存在的问题：
在做实验的过程中碰到一个看似比较小的问题，select * from emp where mgr=7902;，在mgr建立了索引，但未利用索引，而是使用的全表扫描，奇怪的事情，准备打印10046的trace探探究竟，后面有结果会详细说明，也顺便学习下10046的使用。
