當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

oracle11g查询优化器,ORACLE中的优化器

發布時間：2024/8/1 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 oracle11g查询优化器,ORACLE中的优化器小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Oracle的優化器有兩種優化方式：

基于規則的優化方式：Rule-Based Optimization(RBO)

基于成本或者統計信息的優化方式(Cost-Based Optimization：CBO)

RBO方式：RBO自ORACLE 6版以來被采用，有著一套嚴格的使用規則，只要你按照它去寫SQL語句，無論數據表中的內容怎樣，也不會影響到你的“執行計劃”，也就是說對數據不“敏感”。優化器在分析SQL語句時,所遵循的是Oracle內部預定的一些規則。比如我們常見的，當一個where子句中的一列有索引時去走索引。

RBO的規則

Rank Access Path

---- --------------------------------

1 Single row by ROWID

2 Single row by cluster join

3 Single row by hash cluster key with unique or primary key

4 Single row by unique or primary key

5 Cluster join

6 Hash cluster key

7 Indexed cluster key

8 Composite index

9 Single-column index

10 Bounded range search on indexed columns

11 Unbounded range search on indexed columns

12 Sort-merge join

13 MAX or MIN of indexed column

14 ORDER BY on indexed column

15 Full table scanOracle中CBO概述CBO方式：CBO是在ORACLE7 引入，但到ORACLE8i 中才成熟。ORACLE已經聲明在ORACLE9i之后的版本中，RBO將不再支持。CPU Costing的計算方式現在默認為CPU+I/O+memory之和.可通過DBMS_XPLAN.DISPLAY_CURSOR觀察更為詳細的執行計劃。優化器在判斷是否用這種方式時,主要參照的是表及索引的統計信息。統計信息給出表的大小、有少行、每行的長度等信息。這些統計信息起初在庫內是沒有的，是做analyze后才出現的，很多的時侯過期統計信息會令優化器做出一個錯誤的執行計劃,因些應及時更新這些信息。按理，CBO應該自動收集，實際卻不然，有時候在CBO情況下，還必須定期對大表進行分析。

進行查詢時，CBO執行了如下操作：可以看到CBO由查詢轉換器、評估器和計劃生成器這3個組件組成。查詢轉換器查詢語句的形式會影響所產生的執行計劃，查詢轉換器的作用就是改變查詢語句的形式以產生較好的執行計劃。查詢轉換有如下四種機制：

視圖合并(View Merging)、謂詞推進(Predicate Pushing)、非嵌套子查詢(Subquery Unnesting)和物化視圖的查詢重寫(Query Rewrite with Materialized Views)

視圖合并：如果SQL語句中含有視圖，經分析后會把視圖放在獨立的“視圖查詢塊”中，每個視圖會產生一個視圖子計劃，當為整個語句產生執行計劃時，視圖子計劃會被直接拿來使用而不會照顧到語句的整體性，這樣就很容易導致不良執行計劃的生成。視圖合并就是為了去掉“視圖查詢塊”，將視圖合并到一個整體的查詢塊中，這樣就不會有視圖子計劃產生，執行計劃的優良性得到提升。如果用戶由于安全設置問題導致無法正常進行視圖合并，可以使用merge any view或者merge view給用戶賦予相應權限。

謂詞推進：不是所有的視圖都能夠被合并，對于那些不能被合并的視圖Oracle會將相應的謂詞推進到視圖查詢塊中，這些謂詞通常是可索引的或者是過濾性較強的，從而影響視圖子查詢的執行計劃。

非嵌套子查詢：子查詢和視圖一樣也是被放于獨立查詢塊中的，查詢轉換器會將絕大多數子查詢轉換為連接從而合并為同一查詢塊，少量不能被轉換為連接的子查詢，會將它們的子計劃安照一個高效的方式排列。

物化視圖的查詢重寫：當query_rewrite_enabled=true時，查詢轉換器尋找與該查詢語句相關聯的物化視圖，并用物化視圖改寫該查詢語句。

“窺視”(Peeking)用戶定義的綁定變量

在Oracle9i中為查詢轉換器增加了一個功能，就是當用戶使用綁定變量時，查詢轉換器可以“偷窺”綁定變量的實際值。

我們知道使用綁定變量雖然可以有效的減少“硬分析”，但它帶來的負面影響是優化器無法根據實際的數據分布來優化SQL，很有可能本可以走索引的SQL卻做了全表掃描。“窺視”正是為了解決這個問題，但是它并沒有徹底的解決，Oracle只允許第一次調用時進行“窺視”，接下來的調用即使綁定變量的值發生了變化，也仍然是使用第一次生成的執行計劃，這就造成了一個錯誤的執行計劃會被多次使用，10g中的“窺視”也是如此。然而在Oracle 11g里，對這個問題，進行了優化，使用了Adaptive Cursor Sharing，它可以產生多個共享cursor。如果結果集是90%的值，就使用cursor 1，如果是10%的值，就使用corsor 2. 在這個轉換的過程中還是有可能再次產生硬解析，也因此可以產生正確的執行計劃

評估器

評估器通過計算三個值來評估計劃的總體成本：選擇性(Selectivity)、基數(Cardinality)、成本(Cost)。

選擇性：選擇性是指結果集在基數中的比例，基數可以由表、視圖、join或者group by語句產生。選擇性是一個大于0小于1的數，0表示沒有記錄被選定，1表示所有記錄都被選定。統計信息和直方圖關系到選擇性值的準確性。如：name=’Davis’，如果不存在統計信息評估器將根據所用的謂詞來指定一個缺省的選擇性值，此時評估器會始終認為等式謂詞的選擇性比不等式謂詞小，如A=1的選擇性小于A>1；如果存在統計信息而不存在直方圖，此時選擇性值為1/count(distinct name)；如果存在統計信息也存在直方圖，選擇性值則為count(name)where name=’Davis’ / count(name)where name is not null。對于返回查詢結果占表的行數比例比較小的話，使用索引是有效率的，如果比例較大的話，全表掃描會更快一些。

基數：通常表中的行數稱為“基礎基數”(Base cardinality)；當用WHERE中的條件過濾后剩下的行數稱為“有效基數”(Effective cardinality)；連接操作之后產生的結果集行數稱為“連接基數”(Join cardinality)；一個字段DISTINCT之后的行數稱為“DISTINCT基數”；“GROUP基數”(Group cardinality)比較特殊，它與基礎基數和DISTINCT基數有關，例如：group by colx則GROUP基數就等于基礎基數，但是group by colx,coly的GROUP基數則大于max ( distinct cardinality of colx , distinct cardinality of coly )且小于min ( (distinct cardinality of colx * distinct cardinality of coly) , base cardinality)。

成本：就是度量資源消耗的單位。可以理解為執行表掃描、索引掃描、連接、排序等操作所消耗I/O、CPU、內存的數量。

計劃生成器

計劃生成器的作用就是生成大量的執行計劃，然后選擇其中總體成本最低的一個。

由于不同的訪問路徑、連接方式和連接順序可以任意組合，雖然以不同的方式訪問和處理數據，但是可以產生同樣的結果，因此一個SQL可能存在大量不同的執行計劃。但實際上計劃生成器很少會試驗所有的可能存在的執行計劃，如果它發現當前執行計劃的成本已經很低了，它將停止試驗，相反當前計劃的成本如果很高，它將繼續試驗其他執行計劃，因此如果能使計劃生成器一開始就找到成本很低的執行計劃，則會大量減少所消耗的時間，這也正是我們為什么用HINTS來優化 SQL的原因之一。

CBO雖然是基于成本的優化器，但仍然允許以“時間”或者說“響應速度”為優化目標，通過設置OPTIMIZER_MODE或者對具體語句嵌入HINTS都可以指定優化目標。

在CBO下寫SQL語句的注意事項

1、CBO計算各種可能“執行計劃”的“代價”，即cost，從中選用cost最低的方案，作為實際運行方案。各“執行計劃”的cost的計算根據，依賴于數據表中數據的統計分布，ORACLE數據庫本身對該統計分布并不清楚，必須要分析表和相關的索引(使用ANALYZE命令或dbms_stats)，才能搜集到CBO所需的數據。2、使用CBO 時，編寫SQL語句時，不必考慮"FROM" 子句后面的表或視圖的順序和"WHERE" 子句后面的條件順序；ORACLE自7版以來采用的許多新技術都是基于CBO的，如星型連接排列查詢，哈希連接查詢，函數索引，和并行查詢等。

3、如果一個語句使用RBO的執行計劃確實比CBO 好，則可以通過加 " /*+ rule */" 提示，強制使用RBO。

4、使用CBO 時，SQL語句 "FROM" 子句后面的表，最好使用ANALYZE 命令分析過，如果"FROM" 子句后面的是視圖，則此視圖的基礎表，也最好使用ANALYZE 命令分析過；否則，ORACLE 會在執行此SQL語句之前，會自動進行動態采樣分析(動態采樣取決于采樣級別)，有可能會導致SQL語句執行緩慢。筆者個人認為，這在高并發的OLTP系統中較為常見，OLAP系統的性能則較少因為上訴原因導致。

5、使用CBO 時，SQL語句中最好不引用系統數據字典表或視圖，因為系統數據字典表都未被分析過，可能導致極差的“執行計劃”。但是不要擅自對數據字典表做分析，否則可能導致死鎖，或系統性能嚴重下降。如果實在需要對數據字典進行分析，可執行如下命令：

exec dbms_stats.gather_fixed_objects_stats

6、使用CBO 時，必須保證為表和相關的索引搜集足夠的統計數據。對數據經常有增、刪、改的表最好定期對表和索引進行分析，可用SQL語句“analyze table xxx compute statistics for all indexes;"ORACLE掌握了充分反映實際的統計數據，才有可能做出正確的選擇。

7、使用CBO 時，被索引的字段的值的數據分布，往往會影響SQL語句的執行計劃。例如：表emp，共有一百萬行數據，但其中的 emp.deptno列，數據只有4種不同的值，如10、20、30、40。雖然emp數據行有很多，ORACLE缺省認定表中列的值是在所有數據行均勻分布的，也就是說每種deptno值各有25萬數據行與之對應。假設SQL搜索條件DEPTNO=10，利用deptno列上的索引進行數據搜索效率，往往不比全表掃描的高，ORACLE理所當然對索引“視而不見”，認為該索引的選擇性不高。

我們考慮另一種情況，如果一百萬數據行實際不是在4種deptno值間平均分配，其中有99萬行對應著值10，5000行對應值20，3000行對應值 30，2000行對應值40。在這種數據分布圖案中對除值為10外的其它deptno值搜索時，毫無疑問，如果索引能被應用，那么效率會高出很多。我們可以采用對該索引列進行單獨分析，或用analyze語句對該列建立直方圖，對該列搜集足夠的統計數據，使ORACLE在搜索選擇性較高的值能用上索引。CBO的模式

First_Rows_n：意味著Oracle在執行SQL時，優先考慮將結果集中的前n條記錄以最快的速度反饋返回來，而其他的結果并不需要同時返回。雖然返回前n條的執行計劃對于整個sql執行時間有可能不是最快的，但是在返回前n條的處理上卻是最快的。這種需求在一些網站搜索或者BBS分頁上經常看到。

注意：oracle中還有First_Rows這種優化器模式，但是由于靈活性較差，Oracle建議采用First_Rows_n替代請看下面SQLSQL> select /*+ first_rows(10) */ * from (select /*+ first_rows(10) */ a.*,rownum r ?from (select /*+ first_rows(10) */ owner,object_name from t where owner='SYS' order by object_name) a where rownum<=20) ?where r >10上面的SQL每次從結果集中取出10條記錄，記錄按字段object_name排序。需要注意的是，排序字段x必須創建有索引，否則CBO將忽略first_rows_n而使用all_rows。

當使用first_rows_n時，Oracle以最快返回前n條記錄為目的，所以在處理的時候，可能后面的數據還沒提取出來，前面的數據已經返回給用戶了。所以對于這種分頁操作，越靠前面的頁，顯示就欸過需要的時間越短。請看下面的例子SQL> create table t ? as select * from dba_objects;

Table created.

SQL> insert /*+ append */ into t select * from t;

50468 rows created.

SQL> commit;

Commit complete.

SQL> insert /*+ append */ into t select * from t;

100936 rows created.

SQL> commit;

..........................

SQL> insert /*+ append */ into t select * from t;

807488 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from t;

COUNT(*)

----------

1614976

SQL> create index t_owner_oname_idx on t(owner,object_name);

Index created.

SQL> ?exec dbms_stats.gather_table_stats('HR','T',cascade=>true);

PL/SQL procedure successfully completed.

SQL> variable high number

SQL> variable low number

SQL> variable host_variable varchar2(10)

查詢1至10行的數據SQL> exec :high := 10; :low := 1; :host_variable :='SYS'

PL/SQL procedure successfully completed.

SQL> set autotrace on explain

SQL> set timing on

SQL> select ?* from (select a.*,rownum r ?from (select /*+ first_rows(10) */ owner,object_name from t where owner= :host_variable order by object_name) a where rownum<= :high ) ?where r > :low

OWNER ? ?OBJECT_NAME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? R

-------- ---------------------------------------- ----------

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?2

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?3

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?4

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?5

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?6

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?7

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?8

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? ?9

SYS ? ? ?/1000e8d1_LinkedHashMapValueIt ? ? ? ? ? ? ? ? ? 10

9 rows selected.

Elapsed: 00:00:00.01

Execution Plan

----------------------------------------------------------

Plan hash value: 2667857998

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

| ? 0 | SELECT STATEMENT ? ?| ? ? ? ? ? ? ? ? ? | ? ?11 | ?1056 | ? ? 3 ? (0)| 00:00:01 |

|* ?1 | ?VIEW ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? | ? ?11 | ?1056 | ? ? 3 ? (0)| 00:00:01 |

|* ?2 | ? COUNT STOPKEY ? ? | ? ? ? ? ? ? ? ? ? | ? ? ? | ? ? ? | ? ? ? ? ? ?| ? ? ? ? ?|

| ? 3 | ? ?VIEW ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? | ? ?11 | ? 913 | ? ? 3 ? (0)| 00:00:01 |

|* ?4 | ? ? INDEX RANGE SCAN| T_OWNER_ONAME_IDX | ? ?11 | ? 341 | ? ? 3 ? (0)| 00:00:01 |

-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("R">TO_NUMBER(:LOW))

2 - filter(ROWNUM<=TO_NUMBER(:HIGH))

4 - access("OWNER"=:HOST_VARIABLE)查詢70000至70010行的數據SQL> ?exec :high :=700010 ; :low := 700000

PL/SQL procedure successfully completed.SQL> select ?* from (select a.*,rownum r ?from (select /*+ first_rows(10) */ owner,object_name from t where owner= :host_variable order by object_name) a where rownum<= :high ) ?where r > :low

OWNER ? ?OBJECT_NAME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? R

-------- ---------------------------------------- ----------

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700001

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700002

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700003

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700004

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700005

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700006

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700007

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700008

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700009

SYS ? ? ?sun/awt/GlobalCursorManager ? ? ? ? ? ? ? ? ?700010

10 rows selected.

Elapsed: 00:00:00.31