现在由于我们的中间层升级到了10.2.0.4.0,而10G当中 RBO (rule base optimizer已经不再支持了,取而代之的是 CBO(cost base optimizer) 而CBO和RBO之间存在差异,首先从from后面表名的顺序上来说 正好是相反的,因此需要进行一定的改动。 而之前的优化经验告诉我们,这个优化和 以前的已经完全不一样,需要 执行计划的支持才能得到相对准确的判断。
执行计划
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE
1 0 MERGE JOIN (OUTER)
2 1 MERGE JOIN (OUTER)
3 2 SORT (JOIN)
4 3 MERGE JOIN (OUTER)
5 4 SORT (JOIN)
6 5 TABLE ACCESS (BY INDEX ROWID) OF 'AREA'
7 6 NESTED LOOPS
8 7 MERGE JOIN
9 8 SORT (JOIN)
10 9 TABLE ACCESS (FULL) OF 'ACCT_STATUS_TYPE'
11 8 SORT (JOIN)
12 11 TABLE ACCESS (FULL) OF 'ACCOUNT'
13 7 INDEX (RANGE SCAN) OF 'PK_AREA' (NON-UNIQUE)
14 4 SORT (JOIN)
15 14 VIEW
16 15 SORT (UNIQUE)
17 16 TABLE ACCESS (FULL) OF 'B_FREETYPE_ACCT'
18 2 SORT (JOIN)
19 18 VIEW
20 19 SORT (GROUP BY)
21 20 TABLE ACCESS (FULL) OF 'ACCT_2_PAYMENT_ACCT'
22 1 SORT (JOIN)
23 22 TABLE ACCESS (FULL) OF 'ACCOUNT_RELA'
以上是9i的执行计划,根据rightmost 和uppermost的原则,同时根据statement_id和child_id来进行推算。
首先要执行statement_id=0那么就需要statement_id=1执行出来才能执行0,而1 有需要2执行完毕才能执行,因此逐步往下推算。然后在这种情况下 再运用rightmost和uppermost的原则来分析。 那么我们就可以得出来执行顺序
如图所示:
而在10G当中 没有了 statement_id和child_id 例如:
那么这个时候如何来看执行计划的步骤呢? 这个地方我开始也比较困惑,实际上跟9i没有太大的区别,首先还是利用rightmost和uppermost的原则,从ID=0开始往下推算,首先为了满足0,需要执行1,而我们需要2和3执行之后才能满足1的执行条件,那么这个时候就可以适用最右最上原则了,首先执行了id=2,接着需要执行id=3,而id=3的执行前提则是需要4和5被执行出来,再次根据最右最上原则,开始执行id=4这一步,以此类推。是可能这样说大家也还是不太明白,有一个简单的办法,那就是把这段sql在PL/SQL Developer里面 按F5就可以快速查看了,并且还可以看到执行的顺序,多找几段sql,大家多试试 应该就可以轻松的掌握其中的规律了。