[摘錄]Oracle數據庫關于SQL的執行計劃


          摘錄地址:http://lw.upschool.cn/edu/1834/2007/16/10du262259_1.shtml

          本文的目的:
            
            1、說一說Oracle的Optimizer及其相關的一些知識。
            
            2、回答一下為什么有時一個表的某個字段明明有索引,當觀察一些SQL的執行計劃時,發現確不走索引的問題。
            
            3、如果你對 FIRST_ROWS、 ALL_ROWS這兩種模式有疑惑時也可以看一下這篇文章。
            
            開始吧:
            
            Oracle在執行一個SQL之前,首先要分析一下語句的執行計劃,然后再按執行計劃去執行。分析語句的執行計劃的工作是由優化器(Optimizer)來完成的。不同的情況,一條SQL可能有多種執行計劃,但在某一時點,一定只有一種執行計劃是最優的,花費時間是最少的。相信你一定會用Pl/sql Developer、Toad等工具去看一個語句的執行計劃,不過你可能對Rule、Choose、First rows、All rows這幾項有疑問,因為我當初也是這樣的,那時我也疑惑為什么選了以上的不同的項,執行計劃就變了?
            
            1、優化器的優化方式
            
            Oracle的優化器共有兩種的優化方式,即基于規則的優化方式(Rule-Based Optimization,簡稱為RBO)和基于代價的優化方式(Cost-Based Optimization,簡稱為CBO)。
            
            A、RBO方式:優化器在分析SQL語句時,所遵循的是Oracle內部預定的一些規則。比如我們常見的,當一個where子句中的一列有索引時去走索引。
            
            B、CBO方式:依詞義可知,它是看語句的代價(Cost)了,這里的代價主要指Cpu和內存。優化器在判斷是否用這種方式時,主要參照的是表及索引的統計信息。統計信息給出表的大小 、有少行、每行的長度等信息。這些統計信息起初在庫內是沒有的,是你在做analyze后才出現的,很多的時侯過期統計信息會令優化器做出一個錯誤的執行計劃,因些我們應及時更新這些信息。在Oracle8及以后的版本,Oracle列推薦用CBO的方式。
            
            我們要明了,不一定走索引就是優的 ,比如一個表只有兩行數據,一次IO就可以完成全表的檢索,而此時走索引時則需要兩次IO,這時對這個表做全表掃描(full table scan)是最好的。
            
            2、優化器的優化模式(Optermizer Mode)
            
            優化模式包括Rule,Choose,First rows,All rows這四種方式,也就是我們以上所提及的。如下我解釋一下:
            
            Rule:不用多說,即走基于規則的方式。
            
            Choolse:這是我們應觀注的,默認的情況下Oracle用的便是這種方式。指的是當一個表或或索引有統計信息,則走CBO的方式,如果表或索引沒統計信息,表又不是特別的小,而且相應的列有索引時,那么就走索引,走RBO的方式。
            
            First Rows:它與Choose方式是類似的,所不同的是當一個表有統計信息時,它將是以最快的方式返回查詢的最先的幾行,從總體上減少了響應時間。
            
            All Rows:也就是我們所說的Cost的方式,當一個表有統計信息時,它將以最快的方式返回表的所有的行,從總體上提高查詢的吞吐量。沒有統計信息則走基于規則的方式。
            
            3、如何設定選用哪種優化模式
            
            A、Instance級別
            
            我們可以通過在init<SID>.ora文件中設定OPTIMIZER_MODE=RULE、OPTIMIZER_MODE=CHOOSE、OPTIMIZER_MODE=FIRST_ROWS、OPTIMIZER_MODE=ALL_ROWS去選用3所提的四種方式,如果你沒設定OPTIMIZER_MODE參數則默認用的是Choose這種方式。
            
            B、Sessions級別
            
            通過SQL> ALTER SESSION SET OPTIMIZER_MODE=<Mode>;來設定。
            
            C、語句級別
            
            這些需要用到Hint,比如:
            
            SQL> SELECT /*+ RULE */ a.userid,
            2 b.name,
            3 b.depart_name
            4 FROM tf_f_yhda a,
            5 tf_f_depart b
            6 WHERE a.userid=b.userid;
            
            4、為什么有時一個表的某個字段明明有索引,當觀察一些語的執行計劃確不走索引呢?如何解決呢 ?
            
            A、不走索引大體有以下幾個原因
            ♀你在Instance級別所用的是all_rows的方式
            ♀你的表的統計信息(最可能的原因)
            ♀你的表很小,上文提到過的,Oracle的優化器認為不值得走索引。
            
            B、解決方法
            ♀可以修改init<SID>.ora中的OPTIMIZER_MODE這個參數,把它改為Rule或Choose,重起數據庫。也可以使用4中所提的Hint.
            ♀刪除統計信息
            SQL>analyze table table_name delete statistics;
            ♀表小不走索引是對的,不用調的。
            
            5、其它相關
            
            A、如何看一個表或索引是否是統計信息
            
            SQL>SELECT * FROM user_tables
            2 WHERE table_name=<table_name>
            3 AND num_rows is not null;
            SQL>SELECT * FROM user_indexes
            2 WHERE table_name=<table_name>
            3 AND num_rows is not null;
            
            b、如果我們先用CBO的方式,我們應及時去更新表和索引的統計信息,以免生形不切合實的執行計劃。
            
            SQL> ANALYZE TABLE table_name COMPUTE STATISTICS;
            SQL> ANALYZE INDEX index_name ESTIMATE STATISTICS;
            
            具體的ANALYZE語句請參照Oracle8i/9i 的refrence文檔。
            <================end of file“Oracle的優化器(Optimizer)”=====================>
            
            下面的是我的關于一點執行計劃的理解
            
            1。首先要啟動trace的選項:
            set autotrace trace explain
            如果出現下面的錯誤:
            
            SQL> set autotrace trace explain
            SP2-0613: Unable to verify PLAN_TABLE format or existence
            SP2-0611: Error enabling EXPLAIN report
            
            那么要先運行下面的語句:
             @?/rdbms/admin/utlxplan.sql;
            
            2。分析下面的執行計劃:
            
            SQL> select ename,dname  from emp, dept  where emp.deptno=dept.deptno   and dept.dname in ('ACCOUNTING','RESEARCH','SALES','OPERATIONS');
            
            Execution Plan
            ----------------------------------------------------------
            0   SELECT STATEMENT Optimizer=CHOOSE
            1  0  NESTED LOOPS
            2  1   TABLE ACCESS (FULL) OF 'EMP'
            3  1   TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'
            4  3    INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)
            
            關于前面的兩個數字,第一個是狀態ID,第二個是父ID。
            
            就是如下所示:0-->1-->2
                       |
                       |-->3-->4
            在上圖里,0的執行依靠1,1的執行又依賴2和3,2是沒有子ID的,所以2最先執行,然后是4,在然后是3;然后2和3的結果傳回1。
            
            在這個里面0行有個字“Optimizer=CHOOSE”,這個就是上文說的那個oracle的優化器了。
            
            還有,看這個“ INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)”,就知道這個語句運行的時候是走INDEX的。
            
            可以猜測這個SQL是使用的RBO,而不是CBO.
            
            如果讓它變成CBO的話,可以這樣:
            analyze table emp compute statistics;
            analyze table dept compute statistics;
            
            然后再執行一次:
            
            SQL> select ename,dname  from emp, dept  where emp.deptno=dept.deptno   and
             dept.dname in ('ACCOUNTING','RESEARCH','SALES','OPERATIONS');
            
            Execution Plan
            ----------------------------------------------------------
            0   SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=14 Bytes=252)
            1  0  HASH JOIN (Cost=3 Card=14 Bytes=252)
            2  1   TABLE ACCESS (FULL) OF 'DEPT' (Cost=1 Card=3 Bytes=33)
            3  1   TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=14 Bytes=98)
            
            這次執行的時候,就不會走INDEX,而是全表掃描了,因為這個表一共就只有14個記錄。
            
            好了,就先試到這里吧。

          來源:upschool.com.cn
          作者:
          關鍵字:執行計劃
          發表日期:2007-1-6 0:29:56



          歡迎大家訪問我的個人網站 萌萌的IT人

          posted on 2007-06-05 16:59 見酒就暈 閱讀(194) 評論(0)  編輯  收藏 所屬分類: DB

          <2025年6月>
          25262728293031
          1234567
          891011121314
          15161718192021
          22232425262728
          293012345

          導航

          統計

          常用鏈接

          留言簿(3)

          我參與的團隊

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          收藏夾

          BLOG

          FRIENDS

          LIFE

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 天台县| 衡阳市| 海盐县| 湘潭市| 申扎县| 寿光市| 黔南| 赤峰市| 德庆县| 祁东县| 红河县| 汉源县| 孝感市| 洛南县| 大足县| 云浮市| 涟源市| 南丰县| 肇州县| 阿拉尔市| 岐山县| 天峨县| 翁牛特旗| 温泉县| 应城市| 克什克腾旗| 二连浩特市| 通州市| 奈曼旗| 娄底市| 鄂温| 胶南市| 高雄县| 黄冈市| 镇宁| 忻州市| 集贤县| 宿松县| 垦利县| 兰溪市| 睢宁县|