对于查询转化，是优化器的一种功能，较简单的回答，优化器会根据它的推测将你的sql语句以另一种方式展现出来，当然查询结果肯定不变，但性能通常都是较优的。
1. NO_UNNEST: 知道优化器关闭查询unnesting，也就是不让它将子查询保持在VIEW中，打散任何子查询。而unnest则是要求使用子查询转换。
这里还必须提到一个隐藏参数 "_tablescan_cost_plus_one", 这个参数在8i里默认值是false的，到了9i，10g才变成true.这将导致9i以上的full scan的成本增加1，另外还有initrans这个表现出的变化，9i中其默认值为2，即使你指定为1，或者数据字典申明为1。
但如果用create table .. as select 方式创建表，则在ITL(Interested Transaction List)中,事物槽会变成3，即这是block的实际数量为3,而不是2。这样就使得full scan的成本在理想情况下，增加了2.
2. 对于8i，执行计划里可知，优化器忽略了子查询的实际成本，只有外部查询的一次全扫描，这使优化器毫不犹豫地选择full scan。而9i呢，则是将子查询的数量乘上外部表的成本，再加上外部表的一次全扫名的成本，这样就能够反映实际情况吗？在不知道子查询结果集的时候，就悲观地认为子查询全表扫描的结果就是外部查询的结果多少有点武断。于是10g在此基础上作了一定的改变，对成本的计算，按照实际数据的分布，得到一个相对合理的百分比；而对cardinality则用5%(对于绑定变量的估计值)计算出一个相对合理，至少在一般分布的条件下合理的值，计算方式如下selectivity*num of rows*5% . 这都得益于一个隐藏参数: _optimizer_correct_sq_selectivity,10g默认为true,如果改为false，这个值则为5%*5%*num of rows(5%一个是父表一个是子表)；
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/661919/viewspace-1003134/ ，如需转载，请注明出处，否则将追究法律责任。
