对话Oracle大师：有关SQL优化的建议

1:学习oracle的过程中，是往数据库某一方面（比如优化，恢复）专而精学习，还是横向进行广的学习，想听听您的意见？
我个人是两种方式兼有，先是在备份恢复方面钻研的相对深入，后续又在优化器方面做了较深入的钻研，同时从06年开始，我一直坚持在MOS上看Oracle数据库各个方面的文章（这应该算是横向的学习）。

2:在计算索引成本的过程中，在谓词中包含多个列，而且有范围查询时。Effective Index Selectivity，Effective Table Selectivity这两个参数如何去计算？
Jonathan Lewis的《Cost Based Oracle Fundamentals》的第4章“Simple B-tree Access”中详细说明了Effective Index Selectivity和Effective Table Selectivity的算法，你可以去看一下。

3:Oracle在优化in方面，INLIST ITERATOR比采用or展开优化器有哪些优点？
IN-List Expansion / OR Expansion的好处是这样改写成以UNION ALL连接的各个分支后，各个分支就可以各自走索引、分区修剪（Partition Pruning）、表连接等相关的执行计划而互不干扰。但做了IN-List Expansion / OR Expansion的等价改写SQL的效率并不一定会比原SQL要好，这也就意味着IN-List Expansion / OR Expansion一定也是基于成本的，即只有当经过IN-List Expansion / OR Expansion后的等价改写SQL的成本值小于原SQL的成本值时，Oracle才会对目标SQL执行IN-List Expansion / OR Expansion。


4:oracle计算并行成本的时候，是串行成本除以并行度吗？并行扫描的时候，数据不需要使用缓存，直接进行读取块，那这些在成本计算中如何去考虑？
Oracle计算并行成本的公式我也不确定，似乎是没有公开过。CBO在计算成本的时候本来就没有考虑缓存对物理I/O的影响，这也是CBO的局限性之一。


5：在平时创建复合索引的时候，对于范围查询的列，为了减少索引成本，一般都放在索引定义的末尾。但有时候由于clustering_factor的影响，导致按照上述规则建立的索引反而不好，对于clustering_factor比较大，表本身很大，不能通过重建表的方式来降低clustering_factor的情况下，如何去优化sql？
如果是因为聚簇因子的值而导致目标SQL没有走相关的索引并且你又不能重建表，则你可以使用manual类型的sql profile或者SPM固定目标SQL的执行计划。


6:您觉得在sql调优过程中，哪种类型的sql是最难调整的？
最难调的是那种多表关联并且SQL文本极其复杂的SQL，此时你必须要结合执行计划和具体的业务知识来调整，也就是说面对这样的SQL，首先你自己得知道应该走什么样的执行计划。