1，什麼是執行計劃
所謂執行計劃，顧名思義，就是對一個查詢任務，做出一份怎樣去完成任務的詳細方案。舉個生活中的例子，我從珠海要去英國，我可以選擇先去香港然後轉機，也可以先去北京轉機，或者去廣州也可以。但是到底怎樣去英國划算，也就是我的費用最少，這是一件值得考究的事情。同樣對於查詢而言，我們提交的SQL僅僅是描述出了我們的目的地是英國，但至於怎麼去，通常我們的SQL中是沒有給出提示信息的，是由數據庫來決定的。
我們先簡單的看一個執行計劃的對比：
SQL> set autotrace traceonly
執行計劃一：
SQL> select count(*) from t;
COUNT(*)
----------
24815
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 TABLE Access (FULL) OF 'T'
執行計劃二：
SQL> select count(*) from t;
COUNT(*)
24815
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=26 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FULL SCAN) OF 'T_INDEX' (NON-UNIQUE) (Cost=26 Card=28180)
這兩個執行計劃中，第一個表示求和是通過進行全表掃描來做的，把整個表中數據讀入內存來逐條累加;第二個表示根據表中索引，把
整個索引讀進內存來逐條累加，而不用去讀表中的數據。但是這兩種方式到底哪種快呢?通常來說可能二比一快，但也不是絕對的。這是一
個很簡單的例子演示執行計劃的差異。對於複雜的SQL(表連接、嵌套子查詢等)，執行計劃可能幾十種甚至上百種，但是到底那種最好呢?
我們事前並不知道，數據庫本身也不知道，但是數據庫會根據一定的規則或者統計信息(statistics)去選擇一個執行計劃，通常來說選擇的是
比較優的，但也有選擇失誤的時候，這就是這次討論的價值所在。
Oracle優化器模式
Oracle優化器有兩大類，基於規則的和基於代價的，在SQLPLUS中我們可以查看init文件中定義的缺省的優化器模式。
SQL> show parameters optimizer_mode
NAME TYPE VALUE
optimizer_mode string CHOOSE
SQL>
這是Oracle8.1.7 企業版，我們可以看出，默認安裝後數據庫優化器模式爲CHOOSE,我們還可以設置爲 RULE、
FIRST_ROWS,ALL_ROWS。可以在init文件中對整個instance的所有會話設置，也可以單獨對某個會話設置：
SQL> ALTER SESSION SET optimizer_mode = RULE;
會話已更改。
SQL> ALTER SESSION SET optimizer_mode = FIRST_ROWS;
會話已更改。
SQL> ALTER SESSION SET optimizer_mode = ALL_ROWS;
會話已更改。
基於規則的查詢，數據庫根據表和索引等定義信息，按照一定的規則來產生執行計劃;基於代價的查詢，數據庫根據蒐集的表和索引的
數據的統計信息(通過analyze 命令或者使用dbms_stats包來蒐集)綜合來決定選取一個數據庫認爲最優的執行計劃(實際上不一定最優)。
RULE是基於規則的，CHOOSE表示如果查詢的表存在蒐集的統計信息則基於代價來執行(在CHOOSE模式下Oracle採用的是 FIRST_ROWS)
，否則基於規則來執行。在基於代價的兩種方式中，FIRST_ROWS指執行計劃採用最少資源儘快的返回部分結果給客戶端，對於排序分頁
頁顯示這種查詢尤其適用，ALL_ROWS指以總體消耗資源最少的方式返回結果給客戶端。
基於規則的模式下，數據庫的執行計劃通常比較穩定。但在基於代價的模式下，我們纔有更大的機會選擇最優的執行計劃。也由於
Oracle的很多查詢方面的特性必須在基於代價的模式下才能體現出來，所以我們通常不選擇RULE(並且Oracle宣稱從 Oracle 10i版本數據庫
開始將不再支持 RULE)。既然是基於代價的模式，也就是說執行計劃的選擇是根據表、索引等定義和數據的統計信息來決定的，這個統計
信息是根據 analyze 命令或者dbms_stats包來定期蒐集的。首先存在着一種可能，就是由於蒐集信息是一個很消耗資源和時間的動作，尤
其當表數據量很大的時候，因爲蒐集信息是對整個表數據進行重新的完全統計，所以這是我們必須慎重考慮的問題。我們只能在服務器空
閒的時候定期的進行信息蒐集。這說明我們在一段時期內，統計信息可能和數據庫本身的數據並不吻合;另外就是Oracle的統計數據本身也
存在着不精確部分(詳細參考Oracle DOCUMENT)，更重要的一個問題就是及時統計數據相對已經比較準確，但是Oracle的優化器的選擇也
並不是始終是最優的方案。這也倚賴於Oracle對不同執行計劃的代價的計算規則(我們通常是無法知道具體的計算規則的)。這好比我們決定
從香港還是從北京去英國，車票、機票等實際價格到底是怎麼核算出來的我們並不知道，或者說我們現在瞭解的價格信息，在我們乘車前
往的時候，真實價格跟我們的預算已經發生了變化。所有的因素，都將影響我們的整個開銷。
執行計劃穩定性能帶給我們什麼
Oracle存在着執行計劃選擇失誤的可能。這也是我們經常遇見的一些現象，比如總有人說我的程序在測試數據庫中跑的很好，但在產
品數據庫上就是跑的很差，甚至後者硬件條件比前者還好，這到底是爲什麼?硬件資源、統計信息、參數設置都可能對執行計劃產生影響。
由於因素太多，我們總是對未來懷着一種莫名的恐懼，我的產品數據庫上線後到底跑的好不好?於是Oracle提供了一種穩定執行計劃的能力
，也就是把在測試環境中的運行良好的執行計劃所產生的OUTLINES移植到產品數據庫，使得執行計劃不會隨着其他因素的變化而變化。
那麼OUTLINES是什麼呢?先要介紹一個內容，Oracle提供了在SQL中使用HINTS來引導優化器產生我們想要的執行計劃的能力。這在
多表連接、複雜查詢中特別有效。HINTS的類型很多，可以設置優化器目標(RULE、CHOOSE、FIRST_ROWS、ALL_ROWS)，可以指定表
連接的順序，可以指定使用哪個表的哪個索引等等，可以對SQL進行很多精細的控制。通過這種方式產生我們想要的執行計劃的這些
HINTS,Oracle可以存儲這些HINTS，我們稱之爲OUTLINES。通過STORE OUTLINES可以使得我們擁有以後產生相同執行計劃的能力，也
就是使我們擁有了穩定執行計劃的能力。
這裏想給出一個附加的說明就是，實際上，我們通過工具改寫SQL，比如使用SQL EXPERT改寫後的SQL，這些不僅僅是加了HINTS
而且文本都已經發生了變化的SQL，也可以存儲OUTLINES，並可被應用到應用中。但這不是一定生效，我們必須測試檢查是否生效。但由
於就算給了錯誤的OUTLINES,數據庫在執行的時候，也只是忽略過去重新生成執行計劃而不會返回錯誤，所以我們纔敢放心的這麼使用。
當然在Oracle文檔中並沒有指明可以這樣做，文檔中只是說明，如果存在OUTLINES的同時又在SQL中加了HINTS，則會使用OUTLINES而
忽略HINTS。這個功能在LECCO將發佈的產品中會使用這一功能，這樣可以將SQL EXPERT的改寫SQL的能力和穩定執行計劃的能力結合起
來，那麼我們就對不能更改源代碼的應用具有了相當強大的SQL優化能力。
也許我們會有疑問，假如穩定了執行計劃，那還蒐集統計信息幹嗎?這是因爲幾個原因造成的，首先，現在的執行計劃對於未來發生了
變化的數據未必就是合適的，存在着當前的執行計劃不滿足未來數據的變化後的效率，而新的統計信息的情況下所產生的執行計劃也並不
是全部都合理的。那這個時候，我們可以採用新蒐集的統計信息，但是卻對新統計信息下不良的執行計劃採用Oracle提供的執行計劃穩定
性這個能力固定執行計劃，這樣結合起來我們可以建立滿意的高效的數據庫運行環境。
我們還需要關注的一個東西，Oracle提供的dbms_stats包除了具有蒐集統計信息的能力，還具有把數據庫中統計信息(statistics)
export/import的能力，還具有隻蒐集統計信息而使得統計信息不應用於數據庫的能力(把統計信息蒐集到一個特定的表中而不是立即生效)
，在這個基礎上我們就可以把統計信息export出來再import到一個測試環境中，再運行我們的應用，在測試環境中我們觀察最新的統計信
息會導致哪些執行計劃發生變化(DB EXPERT的Plan Version Tracer是模擬不同環境並自動檢查不同環境中執行計劃變化的工具)，是變好了
還是變差了。我們可以把變差的這一部分在測試環境中使用hints或者利用工具(SQL EXPERT是在重寫SQL這一領域目前最強有力的工具)產
生良好的執行計劃的SQL，利用這些SQL可以產生OUTLINES,然後在產品數據庫應用最新的統計信息的同時移植進這些OUTLINES。
最後說一下我們不得不使用執行計劃穩定性能力的場合。我們假定Oracle的優化器的選擇都是準確的，但是優化器選擇的基礎就是我
們的SQL,這些SQL才從根本上決定了運行效率，這是更重要的一個優化的環節。SQL是基礎(當然數據庫的設計是基礎的基礎)，一個SQL寫
的好不好，就相當於我們同樣是要想去英國，但是我的起點在珠海，你的起點卻在西藏的最邊緣偏僻的一個地方，那不管你做怎樣的最優
路線選擇，你都不如我在珠海去英國所花費的代價小。
2，怎麼生成的
1.Explain plan
explain plan for
select * from aa;
查看結果：
select * from table(dbms_xplan.display());
2.Autotrace
Set timing on --記錄所用時間
Set autottrace on/traceonly--自動記錄執行計劃
3.SQL_TRACE
ORACLE SQL_TRACE
“SQL TRACE”是Oracle提供的用於進行SQL跟蹤的手段，是強有力的輔助診斷工具。在日常的數據庫問題診斷和解決中，“SQL TRACE”是
非常常用的方法。
一般，一次跟蹤可以分爲以下幾步：
1、界定需要跟蹤的目標範圍，並使用適當的命令啓用所需跟蹤。
2、經過一段時間後，停止跟蹤。此時應該產生了一個跟蹤結果文件。
3、找到跟蹤文件，並對其進行格式化，然後閱讀或分析。
本文就“SQL TRACE”的這些使用作簡單探討，並通過具體案例對SQL_TRACE的使用進行說明。
3，怎麼查看執行計劃
從Oracle10g開始，可以通過EXPLAIN PLAN FOR查看DDL語句的執行計劃了。
在9i及以前版本，Oracle只能看到DML的執行計劃，不過從10g開始，通過EXPLAIN PLAN FOR的方式，已經可以看到DDL語句的執行計劃
了。
這對於研究CREATE TABLE AS SELECT、CREATE MATERIALIZED VIEW AS SELECT以及CREATE INDEX，ALTER INDEX REBUILD等語
句有很大的幫助。
舉個簡單的例子，Oracle的文檔上對於索引的建立有如下描述：
The optimizer can use an existing index to build another index. This results in a much faster index build.
如果看不到DDL的執行計劃，只能根據執行時間的長短去猜測Oracle的具體執行計劃，但是這種方法沒有足夠的說服力。但是通過DDL的執
行計劃，就使得結果一目瞭然了。
SQL> CREATE TABLE T AS SELECT * FROM DBA_OBJECTS;
表已創建。
SQL> EXPLAIN PLAN FOR
2 CREATE INDEX IND_T_NAME ON T(OBJECT_NAME);
已解釋。
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------
Plan hash value: 3035241083
-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | CREATE INDEX STATEMENT | | 57915 | 3732K| 75 (2)| 00:00:01 |
| 1 | INDEX BUILD NON UNIQUE| IND_T_NAME | | | | |
| 2 | SORT CREATE INDEX | | 57915 | 3732K| | |
| 3 | TABLE ACCESS FULL | T | 57915 | 3732K| 41 (3)| 00:00:01 |
-------------------------------------------------------------------------------------
Note
-----
- estimated index size: 5242K bytes
已選擇14行。
SQL> CREATE INDEX IND_T_OWNER_NAME ON T(OWNER, OBJECT_NAME);
索引已創建。
SQL> EXPLAIN PLAN FOR
2 CREATE INDEX IND_T_NAME ON T(OBJECT_NAME);
已解釋。
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------
Plan hash value: 517242163
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | CREATE INDEX STATEMENT | | 57915 | 3732K| 75 (2)| 00:00:01 |
| 1 | INDEX BUILD NON UNIQUE| IND_T_NAME | | | | |
| 2 | SORT CREATE INDEX | | 57915 | 3732K| | |
| 3 | INDEX FAST FULL SCAN| IND_T_OWNER_NAME | | | | |
-------------------------------------------------------------------------------------------
Note
-----
- estimated index size: 5242K bytes
已選擇14行。
SQL> SET AUTOT ON
SQL> CREATE INDEX IND_T_NAME ON T(OBJECT_NAME);
索引已創建。
注意，查看DDL的執行計劃需要使用EXPLAIN PLAN FOR，AUTOTRACE對於DDL是無效的。
4，如何讀懂執行計劃：
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'USER_INFO'
3 2 NESTED LOOPS
4 3 TABLE ACCESS (FULL) OF 'USER_NUM_TABLE'
5 3 INDEX (RANGE SCAN) OF 'PK_USER_INFO' (UNIQUE)
請問以上執行計劃語句是如何看的？語句的執行順序是什麼？
讓我們來解釋一下怎麼看吧,左邊的兩列數字，第一列表示這條計劃的編號，第二列是這條計劃的父計劃的編號；如果一條計劃有子計劃，
那麼先要執行其子計劃;在這個例子中：從第一條編號爲0的（SELECT STATEMENT ptimizer=CHOOSE）開始，他有個子計劃1（SORT
(AGGREGATE)），然後1有個子計劃2，2有子計劃3， 3 有子計劃4和5，4是3的第一個子計劃，所以先執行4（TABLE ACCESS (FULL)
OF 'USER_NUM_TABLE'），再執行5(INDEX (RANGE SCAN) OF 'PK_USER_INFO' (UNIQUE))，4和5執行完返回到其父計劃3（NESTED
LOOPS），3把4和5取到的rows進行nested loops，結果再返回到2，再到1排序，再到0select.
舉例：
SQL> conn scott/tiger
已連接。
SQL> set autotrace traceonly;
SQL> SELECT count(1) FROM dim_hy;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'DIM_HY' (Cost=6 Card=1801)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
45 consistent gets
0 physical reads
0 redo size
377 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> desc dim_hy
名稱 是否爲空? 類型
----------------------------------------- -------- ----------------------------
HY_ID NOT NULL NUMBER(10)
HY_DM NOT NULL VARCHAR2(6)
HY_MC NOT NULL VARCHAR2(40)
HY_MXID NUMBER(10)
HY_MXDM VARCHAR2(6)
HY_MXMC VARCHAR2(40)
HY_ZLID NUMBER(10)
HY_ZLDM VARCHAR2(6)
HY_ZLMC VARCHAR2(40)
HY_DLID NUMBER(10)
HY_DLDM VARCHAR2(6)
HY_DLMC VARCHAR2(40)
HY_MLID NUMBER(10)
HY_MLDM VARCHAR2(6)
HY_MLMC VARCHAR2(30)
HY_CCLX NOT NULL VARCHAR2(10)
HY_CCMC NOT NULL VARCHAR2(10)
CY_ID NUMBER(6)
CY_LXDM CHAR(1)
CY_LXMS VARCHAR2(20)
HY_SJ_ID NUMBER(10)
YXBZ NOT NULL CHAR(1)
YXQQ NOT NULL DATE
YXQZ NOT NULL DATE
SQL> CREATE INDEX idx_dim_hy ON dim_hy(hy_id);
索引已創建。
SQL> SELECT count(1) FROM dim_hy;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'IDX_DIM_HY' (NON-UNIQUE) (Cos
t=4 Card=1801)
Statistics
----------------------------------------------------------
14 recursive calls
0 db block gets
10 consistent gets
4 physical reads
0 redo size
377 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
================================================================================================
SQL> conn sys/sys as sysdba
已連接。
SQL> show parameter optimizer_mode;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_mode string CHOOSE
SQL> ALTER SESSION SET optimizer_mode = RULE;
會話已更改。
SQL> ALTER SESSION SET optimizer_mode = TEST ;
ERROR:
ORA-00096: 值 TEST 對參數 optimizer_mode 無效，它必須來自 first_rows_1000,
first_rows_100, first_rows_10, first_rows_1, first_rows, all_rows, choose, rule
之間
SQL> ALTER SESSION SET optimizer_mode = CHOOSE;
會話已更改。
==================================================================================================
SQL> EXPLAIN PLAN FOR SELECT count(*) FROM dim_hy;
已解釋。
SQL> SELECT * FROM TABLE(dbms_xplan.display()) ;
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 4 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| IDX_DIM_HY | 1801 | | 4 |
---------------------------------------------------------------------
Note: cpu costing is off
已選擇10行。
SQL> SET TIMING ON;
SQL> EXPLAIN PLAN FOR SELECT count(1) FROM dim_hy;
已解釋。
已用時間: 00: 00: 00.00
SQL> SELECT * FROM TABLE(dbms_xplan.display()) ;
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 4 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| IDX_DIM_HY | 1801 | | 4 |
---------------------------------------------------------------------
Note: cpu costing is off
已選擇10行。
已用時間: 00: 00: 00.00
======================================================================================
SQL> CREATE TABLE hy AS SELECT * FROM dim_hy;
表已創建。
已用時間: 00: 00: 00.04
SQL> EXPLAIN PLAN FOR CREATE INDEX idx_hy_id ON hy(hy_id);
已解釋。
已用時間: 00: 00: 00.00
SQL> SELECT * FROM TABLE(dbms_xplan.display()) ;
已選擇11行。
已用時間: 00: 00: 00.00
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
Statistics
----------------------------------------------------------
13 recursive calls
0 db block gets
22 consistent gets
0 physical reads
0 redo size
1061 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
9 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> SELECT * FROM hy;
已選擇1801行。
已用時間: 00: 00: 00.01
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'HY'
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
162 consistent gets
42 physical reads
0 redo size
139471 bytes sent via SQL*Net to client
1823 bytes received via SQL*Net from client
122 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1801 rows processed
SQL> SELECT * FROM TABLE(dbms_xplan.display()) ;
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
----------------------------------------------------------------------
| 0 | CREATE INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_HY_ID | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | HY | | | |
----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
===========================================================================================
SQL> SET AUTOTRACE TRACEONLY;
SQL> SELECT m.hy_id, n.hy_mc FROM hy m, dim_hy n WHERE m.hy_id = n.hy_id ;
已選擇1801行。
已用時間: 00: 00: 00.01
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=13 Card=1801 Bytes=5
5831)
1 0 HASH JOIN (Cost=13 Card=1801 Bytes=55831)
2 1 TABLE ACCESS (FULL) OF 'HY' (Cost=6 Card=1801 Bytes=2341
3)
3 1 TABLE ACCESS (FULL) OF 'DIM_HY' (Cost=6 Card=1801 Bytes=
32418)
Statistics
----------------------------------------------------------
31 recursive calls
0 db block gets
258 consistent gets
0 physical reads
0 redo size
52655 bytes sent via SQL*Net to client
1823 bytes received via SQL*Net from client
122 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1801 rows processed
==============================================================================================================================================================================
本文全面詳細介紹oracle執行計劃的相關的概念，訪問數據的存取方法，表之間的連接等內容。
並有總結和概述，便於理解與記憶!
+++
目錄
---
一．相關的概念
Rowid的概念
Recursive Sql概念
Predicate(謂詞)
DRiving Table(驅動表)
Probed Table(被探查表)
組合索引(concatenated index)
可選擇性(selectivity)
二．oracle訪問數據的存取方法
1） 全表掃描（Full Table Scans， FTS）
2） 通過ROWID的表存取（Table Access by ROWID或rowid lookup）
3）索引掃描（Index Scan或index lookup）有4種類型的索引掃描：
（1） 索引唯一掃描（index unique scan）
（2） 索引範圍掃描（index range scan）
在非唯一索引上都使用索引範圍掃描。使用index rang scan的3種情況：
（a） 在唯一索引列上使用了range操作符（> < <> >= <= between）
（b） 在組合索引上，只使用部分列進行查詢，導致查詢出多行
（c） 對非唯一索引列上進行的任何查詢。
（3） 索引全掃描（index full scan）
（4） 索引快速掃描（index fast full scan）
三、表之間的連接
1，排序 - - 合併連接（Sort Merge Join， SMJ）
2，嵌套循環（Nested Loops， NL）
3，哈希連接（Hash Join， HJ）
另外，笛卡兒乘積（Cartesian Product）
總結Oracle連接方法
Oracle執行計劃總結概述
+++
一．相關的概念
Rowid的概念：rowid是一個僞列，既然是僞列，那麼這個列就不是用戶定義，而是系統自己給加上的。 對每個表都有一個rowid的僞列，但是表中並不物理存儲ROWID列的值。不過你可以像使用其它列那樣使用它，但是不能刪除改列，也不能對該列的值進行 修改、插入。一旦一行數據插入數據庫，則rowid在該行的生命週期內是唯一的，即即使該行產生行遷移，行的rowid也不會改變。
Recursive SQL概念：有時爲了執行用戶發出的一個sql語句，Oracle必須執行一些額外的語句，我們將這些額外的語句稱之爲''recursive calls''或''recursive SQL statements''.如當一個DDL語句發出後，ORACLE總是隱含的發出一些recursive SQL語句，來修改數據字典信息，以便用戶可以成功的執行該DDL語句。當需要的數據字典信息沒有在共享內存中時，經常會發生Recursive calls，這些Recursive calls會將數據字典信息從硬盤讀入內存中。用戶不比關心這些recursive
SQL語句的執行情況，在需要的時候，ORACLE會自動的在內部執行這些語句。當然DML語句與SELECT都可能引起recursive SQL.簡單的說，我們可以將觸發器視爲recursive SQL.
Row Source（行源）：用在查詢中，由上一操作返回的符合條件的行的集合，即可以是表的全部行數據的集合；也可以是表的部分行數據的集合；也可以爲對上2個row source進行連接操作（如join連接）後得到的行數據集合。
Predicate（謂詞）：一個查詢中的WHERE限制條件
Driving Table（驅動表）：該表又稱爲外層表（OUTER TABLE）。這個概念用於嵌套與HASH連接中。如果該row source返回較多的行數據，則對所有的後續操作有負面影響。注意此處雖然翻譯爲驅動表，但實際上翻譯爲驅動行源（driving row source）更爲確切。一般說來，是應用查詢的限制條件後，返回較少行源的表作爲驅動表，所以如果一個大表在WHERE條件有有限制條件（如等值限 制），則該大表作爲驅動表也是合適的，所以並不是只有較小的表可以作爲驅動表，正確說法應該爲應用查詢的限制條件後，返回較少行源的表作爲驅動表。在執行
計劃中，應該爲靠上的那個row source，後面會給出具體說明。在我們後面的描述中，一般將該表稱爲連接操作的row source 1.
Probed Table（被探查表）：該表又稱爲內層表（INNER TABLE）。在我們從驅動表中得到具體一行的數據後，在該表中尋找符合連接條件的行。所以該表應當爲大表（實際上應該爲返回較大row source的表）且相應的列上應該有索引。在我們後面的描述中，一般將該表稱爲連接操作的row source 2.
組合索引（concatenated index）：由多個列構成的索引，如create index idx_emp on emp（col1， col2， col3， ……），則我們稱idx_emp索引爲組合索引。在組合索引中有一個重要的概念：引導列（leading column），在上面的例子中，col1列爲引導列。當我們進行查詢時可以使用“where col1 = ？ ”，也可以使用“where col1 = ？ and col2 = ？”，這樣的限制條件都會使用索引，但是“where col2 = ？
”查詢就不會使用該索引。所以限制條件中包含先導列時，該限制條件纔會使用該組合索引。
可選擇性（selectivity）：比較一下列中唯一鍵的數量和表中的行數，就可以判斷該列的可選擇性。 如果該列的“唯一鍵的數量/表中的行數”的比值越接近1，則該列的可選擇性越高，該列就越適合創建索引，同樣索引的可選擇性也越高。在可選擇性高的列上進 行查詢時，返回的數據就較少，比較適合使用索引查詢。
二．oracle訪問數據的存取方法
1） 全表掃描（Full Table Scans， FTS）
爲實現全表掃描，Oracle讀取表中所有的行，並檢查每一行是否滿足語句的WHERE限制條件一個多塊讀操作可以使一次I/O能讀取多塊數據塊（db_block_multiblock_read_count參數設定），而不是隻讀取一個數據塊，這極大的減 少了I/O總次數，提高了系統的吞吐量，所以利用多塊讀的方法可以十分高效地實現全表掃描，而且只有在全表掃描的情況下才能使用多塊讀操作。在這種訪問模 式下，每個數據塊只被讀一次。
使用FTS的前提條件：在較大的表上不建議使用全表掃描，除非取出數據的比較多，超過總量的5% —— 10%，或你想使用並行查詢功能時。
使用全表掃描的例子：
SQL> explain plan for select * from dual;
Query Plan
-----------------------------------------
SELECT STATEMENT[CHOOSE] Cost=
TABLE ACCESS FULL DUAL
2） 通過ROWID的表存取（Table Access by ROWID或rowid lookup）
行的ROWID指出了該行所在的數據文件、數據塊以及行在該塊中的位置，所以通過ROWID來存取數據可以快速定位到目標數據上，是Oracle存取單行數據的最快方法。
這種存取方法不會用到多塊讀操作，一次I/O只能讀取一個數據塊。我們會經常在執行計劃中看到該存取方法，如通過索引查詢數據。
使用ROWID存取的方法：
SQL> explain plan for select * from dept where rowid = ''AAAAyGAADAAAAATAAF''；
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID DEPT [ANALYZED]
3）索引掃描（Index Scan或index lookup）
我們先通過index查找到數據對應的rowid值（對於非唯一索引可能返回多個rowid值），然後根據rowid直接從表中得到具體的數據，這 種查找方式稱爲索引掃描或索引查找（index lookup）。一個rowid唯一的表示一行數據，該行對應的數據塊是通過一次i/o得到的，在此情況下該次i/o只會讀取一個數據庫塊。
在索引中，除了存儲每個索引的值外，索引還存儲具有此值的行對應的ROWID值。
索引掃描可以由2步組成：
（1） 掃描索引得到對應的rowid值。
（2） 通過找到的rowid從表中讀出具體的數據。
每步都是單獨的一次I/O，但是對於索引，由於經常使用，絕大多數都已經CACHE到內存中，所以第1步的 I/O經常是邏輯I/O，即數據可以從內存中得到。但是對於第2步來說，如果表比較大，則其數據不可能全在內存中，所以其I/O很有可能是物理I/O，這 是一個機械操作，相對邏輯I/O來說，是極其費時間的。所以如果多大表進行索引掃描，取出的數據如果大於總量的5% —— 10%，使用索引掃描會效率下降很多。如下列所示：
SQL> explain plan for select empno， ename from emp where empno=10；
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1
但是如果查詢的數據能全在索引中找到，就可以避免進行第2步操作，避免了不必要的I/O，此時即使通過索引掃描取出的數據比較多，效率還是很高的
SQL> explain plan for select empno from emp where empno=10;-- 只查詢empno列值
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX UNIQUE SCAN EMP_I1
進一步講，如果sql語句中對索引列進行排序，因爲索引已經預先排序好了，所以在執行計劃中不需要再對索引列進行排序
SQL> explain plan for select empno, ename from emp
where empno > 7876 order by empno;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]
從這個例子中可以看到：因爲索引是已經排序了的，所以將按照索引的順序查詢出符合條件的行，因此避免了進一步排序操作。
根據索引的類型與where限制條件的不同，有4種類型的索引掃描：
索引唯一掃描（index unique scan）
索引範圍掃描（index range scan）
索引全掃描（index full scan）
索引快速掃描（index fast full scan）
（1） 索引唯一掃描（index unique scan）
通過唯一索引查找一個數值經常返回單個ROWID.如果存在UNIQUE 或PRIMARY KEY 約束（它保證了語句只存取單行）的話，Oracle經常實現唯一性掃描。
使用唯一性約束的例子：
SQL> explain plan for
select empno，ename from emp where empno=10；
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1
（2） 索引範圍掃描（index range scan）
使用一個索引存取多行數據，在唯一索引上使用索引範圍掃描的典型情況下是在謂詞（where限制條件）中使用了範圍操作符（如>、<、<>、>=、<=、between）
使用索引範圍掃描的例子：
SQL> explain plan for select empno，ename from emp
where empno > 7876 order by empno；
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]
在非唯一索引上，謂詞col = 5可能返回多行數據，所以在非唯一索引上都使用索引範圍掃描。
使用index rang scan的3種情況：
（a） 在唯一索引列上使用了range操作符（> < <> >= <= between）
（b） 在組合索引上，只使用部分列進行查詢，導致查詢出多行
（c） 對非唯一索引列上進行的任何查詢。
（3） 索引全掃描（index full scan）
與全表掃描對應，也有相應的全索引掃描。而且此時查詢出的數據都必須從索引中可以直接得到。
全索引掃描的例子：
An Index full scan will not perform. single block i/o''s and so it may prove to be inefficient.
e.g.
Index BE_IX is a concatenated index on big_emp （empno， ename）
SQL> explain plan for select empno， ename from big_emp order by empno，ename；
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT[CHOOSE] Cost=26
INDEX FULL SCAN BE_IX [ANALYZED]
（4） 索引快速掃描（index fast full scan）
掃描索引中的所有的數據塊，與 index full scan很類似，但是一個顯著的區別就是它不對查詢出的數據進行排序，即數據不是以排序順序被返回。在這種存取方法中，可以使用多塊讀功能，也可以使用並行讀入，以便獲得最大吞吐量與縮短執行時間。
索引快速掃描的例子：
BE_IX索引是一個多列索引： big_emp （empno，ename）
SQL> explain plan for select empno，ename from big_emp；
Query Plan
------------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]
只選擇多列索引的第2列：
SQL> explain plan for select ename from big_emp；
Query Plan
------------------------------------------
SELECT STATEMENT[CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]
三、表之間的連接
Join是一種試圖將兩個表結合在一起的謂詞，一次只能連接2個表，表連接也可以被稱爲表關聯。在後面的敘 述中，我們將會使用“row source”來代替“表”，因爲使用row source更嚴謹一些，並且將參與連接的2個row source分別稱爲row source1和row source 2.Join過程的各個步驟經常是串行操作，即使相關的row source可以被並行訪問，即可以並行的讀取做join連接的兩個row source的數據，但是在將表中符合限制條件的數據讀入到內存形成row source後，join的其它步驟一般是串行的。有多種方法可以將2個表連接起來，當然每種方法都有自己的優缺點，每種連接類型只有在特定的條件下才會
發揮出其最大優勢。
row source（表）之間的連接順序對於查詢的效率有非常大的影響。通過首先存取特定的表，即將該表作爲驅動表，這樣可以先應用某些限制條件，從而得到一個 較小的row source，使連接的效率較高，這也就是我們常說的要先執行限制條件的原因。一般是在將表讀入內存時，應用where子句中對該表的限制條件。
根據2個row source的連接條件的中操作符的不同，可以將連接分爲等值連接（如WHERE A.COL3 = B.COL4）、非等值連接（WHERE A.COL3 > B.COL4）、外連接（WHERE A.COL3 = B.COL4（+））。上面的各個連接的連接原理都基本一樣，所以爲了簡單期間，下面以等值連接爲例進行介紹。
在後面的介紹中，都以以下Sql爲例進行說明：
SELECT A.COL1， B.COL2
FROM A， B
WHERE A.COL3 = B.COL4；
假設A表爲Row Soruce1，則其對應的連接操作關聯列爲COL 3；
B表爲Row Soruce2，則其對應的連接操作關聯列爲COL 4；
連接類型：
目前爲止，無論連接操作符如何，典型的連接類型共有3種：
排序 - - 合併連接（Sort Merge Join （SMJ） ）
嵌套循環（Nested Loops （NL） ）
哈希連接（Hash Join）
另外，還有一種Cartesian product（笛卡爾積），一般情況下，儘量避免使用。
1，排序 - - 合併連接（Sort Merge Join， SMJ）
內部連接過程：
1） 首先生成row source1需要的數據，然後對這些數據按照連接操作關聯列（如A.col3）進行排序。
2） 隨後生成row source2需要的數據，然後對這些數據按照與sort source1對應的連接操作關聯列（如B.col4）進行排序。
3） 最後兩邊已排序的行被放在一起執行合併操作，即將2個row source按照連接條件連接起來
下面是連接步驟的圖形表示：
MERGE
/\
SORTSORT
||
Row Source 1Row Source 2
如果row source已經在連接關聯列上被排序，則該連接操作就不需要再進行sort操作，這樣可以大大提高這種連接操作的連接速度，因爲排序是個極其費資源的操 作，特別是對於較大的表。預先排序的row source包括已經被索引的列（如a.col3或b.col4上有索引）或row source已經在前面的步驟中被排序了。儘管合併兩個row source的過程是串行的，但是可以並行訪問這兩個row source（如並行讀入數據，並行排序）。
SMJ連接的例子：
SQL> explain plan for
select/*+ ordered */e.deptno， d.deptno
from emp e， dept d
where e.deptno = d.deptno
order by e.deptno， d.deptno；
Query Plan
-------------------------------------
SELECT STATEMENT [CHOOSE] Cost=17
MERGE JOIN
SORT JOIN
TABLE ACCESS FULL EMP [ANALYZED]
SORT JOIN
TABLE ACCESS FULL DEPT [ANALYZED]
排序是一個費時、費資源的操作，特別對於大表。基於這個原因，SMJ經常不是一個特別有效的連接方法，但是如果2個row source都已經預先排序，則這種連接方法的效率也是蠻高的。
2，嵌套循環（Nested Loops， NL）
這個連接方法有驅動表（外部表）的概念。其實，該連接過程就是一個2層嵌套循環，所以外層循環的次數越少越好，這也就是我們爲什麼將小表或返回較小 row source的表作爲驅動表（用於外層循環）的理論依據。但是這個理論只是一般指導原則，因爲遵循這個理論並不能總保證使語句產生的I/O次數最少。有時 不遵守這個理論依據，反而會獲得更好的效率。如果使用這種方法，決定使用哪個表作爲驅動表很重要。有時如果驅動表選擇不正確，將會導致語句的性能很差、很差。
內部連接過程：
Row source1的Row 1 —— Probe ->Row source 2
Row source1的Row 2 —— Probe ->Row source 2
Row source1的Row 3 —— Probe ->Row source 2
……。
Row source1的Row n —— Probe ->Row source 2
從內部連接過程來看，需要用row source1中的每一行，去匹配row source2中的所有行，所以此時保持row source1儘可能的小與高效的訪問row source2（一般通過索引實現）是影響這個連接效率的關鍵問題。這只是理論指導原則，目的是使整個連接操作產生最少的物理I/O次數，而且如果遵守這 個原則，一般也會使總的物理I/O數最少。但是如果不遵從這個指導原則，反而能用更少的物理I/O實現連接操作，那儘管違反指導原則吧！因爲最少的物理 I/O次數纔是我們應該遵從的真正的指導原則，在後面的具體案例分析中就給出這樣的例子。
在上面的連接過程中，我們稱Row source1爲驅動表或外部表。Row Source2被稱爲被探查表或內部表。
在NESTED LOOPS連接中，Oracle讀取row source1中的每一行，然後在row sourc2中檢查是否有匹配的行，所有被匹配的行都被放到結果集中，然後處理row source1中的下一行。這個過程一直繼續，直到row source1中的所有行都被處理。這是從連接操作中可以得到第一個匹配行的最快的方法之一，這種類型的連接可以用在需要快速響應的語句中，以響應速度爲 主要目標。
如果driving row source（外部表）比較小，並且在inner row source（內部表）上有唯一索引，或有高選擇性非唯一索引時，使用這種方法可以得到較好的效率。NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返回數據，這可以實現快速的響應時間。
如果不使用並行操作，最好的驅動表是那些應用了where 限制條件後，可以返回較少行數據的的表，所以大表也可能稱爲驅動表，關鍵看限制條件。對於並行查詢，我們經常選擇大表作爲驅動表，因爲大表可以充分利用並 行功能。當然，有時對查詢使用並行操作並不一定會比查詢不使用並行操作效率高，因爲最後可能每個表只有很少的行符合限制條件，而且還要看你的硬件配置是否 可以支持並行（如是否有多個CPU，多個硬盤控制器），所以要具體問題具體對待。
NL連接的例子：
SQL> explain plan for
select a.dname，b.sql
from dept a，emp b
where a.deptno = b.deptno；
Query Plan
-------------------------
SELECT STATEMENT [CHOOSE] Cost=5
NESTED LOOPS
TABLE ACCESS FULL DEPT [ANALYZED]
TABLE ACCESS FULL EMP [ANALYZED]
3，哈希連接（Hash Join， HJ）
這種連接是在oracle 7.3以後引入的，從理論上來說比NL與SMJ更高效，而且只用在CBO優化器中。
較小的row source被用來構建hash table與bitmap，第2個row source被用來被hansed，並與第一個row source生成的hash table進行匹配，以便進行進一步的連接。Bitmap被用來作爲一種比較快的查找方法，來檢查在hash table中是否有匹配的行。特別的，當hash table比較大而不能全部容納在內存中時，這種查找方法更爲有用。這種連接方法也有NL連接中所謂的驅動表的概念，被構建爲hash table與bitmap的表爲驅動表，當被構建的hash table與bitmap能被容納在內存中時，這種連接方式的效率極高。
HASH連接的例子：
SQL> explain plan for
select/*+ use_hash（emp） */empno
from emp， dept
where emp.deptno = dept.deptno；
Query Plan
----------------------------
SELECT STATEMENT[CHOOSE] Cost=3
HASH JOIN
TABLE ACCESS FULL DEPT
TABLE ACCESS FULL EMP
要使哈希連接有效，需要設置HASH_JOIN_ENABLED=TRUE，缺省情況下該參數爲TRUE，另外，不要忘了還要設置 hash_area_size參數，以使哈希連接高效運行，因爲哈希連接會在該參數指定大小的內存中運行，過小的參數會使哈希連接的性能比其他連接方式還 要低。
另外，笛卡兒乘積（Cartesian Product）
當兩個row source做連接，但是它們之間沒有關聯條件時，就會在兩個row source中做笛卡兒乘積，這通常由編寫代碼疏漏造成（即程序員忘了寫關聯條件）。笛卡爾乘積是一個表的每一行依次與另一個表中的所有行匹配。在特殊情況下我們可以使用笛卡兒乘積，如在星形連接中，除此之外，我們要儘量不使用笛卡兒乘積，否則，自己想結果是什麼吧！
注意在下面的語句中，在2個表之間沒有連接。
SQL> explain plan for
select emp.deptno，dept，deptno
from emp，dept
Query Plan
------------------------
SLECT STATEMENT [CHOOSE] Cost=5
MERGE JOIN CARTESIAN
TABLE ACCESS FULL DEPT
SORT JOIN
TABLE ACCESS FULL EMP
CARTESIAN關鍵字指出了在2個表之間做笛卡爾乘積。假如表emp有n行，dept表有m行，笛卡爾乘積的結果就是得到n * m行結果。
最後，總結一下，在哪種情況下用哪種連接方法比較好：
排序 - - 合併連接（Sort Merge Join， SMJ）：
a） 對於非等值連接，這種連接方式的效率是比較高的。
b） 如果在關聯的列上都有索引，效果更好。
c） 對於將2個較大的row source做連接，該連接方法比NL連接要好一些。
d） 但是如果sort merge返回的row source過大，則又會導致使用過多的rowid在表中查詢數據時，數據庫性能下降，因爲過多的I/O.
嵌套循環（Nested Loops， NL）：
a） 如果driving row source（外部表）比較小，並且在inner row source（內部表）上有唯一索引，或有高選擇性非唯一索引時，使用這種方法可以得到較好的效率。
b） NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返回數據，這可以實現快速的響應時間。
哈希連接（Hash Join， HJ）：
a） 這種方法是在oracle7後來引入的，使用了比較先進的連接理論，一般來說，其效率應該好於其它2種連接，但是這種連接只能用在CBO優化器中，而且需要設置合適的hash_area_size參數，才能取得較好的性能。
b） 在2個較大的row source之間連接時會取得相對較好的效率，在一個row source較小時則能取得更好的效率。
c） 只能用於等值連接中
+++
Oracle執行計劃的概述
---
Oracle執行計劃的相關概念：
Rowid：系統給oracle數據的每行附加的一個僞列，包含數據表名稱，數據庫id，存儲數據庫id以及一個流水號等信息，rowid在行的生命週期內唯一。
Recursive sql：爲了執行用戶語句，系統附加執行的額外操作語句，譬如對數據字典的維護等。
Row source（行源）：oracle執行步驟過程中，由上一個操作返回的符合條件的行的集合。
Predicate（謂詞）：where後的限制條件。
Driving table（驅動表）：又稱爲連接的外層表，主要用於嵌套與hash連接中。一般來說是將應用限制條件後，返回較少行源的表作爲驅動表。在後面的描述中，將driving table稱爲連接操作的row source 1。
Probed table（被探查表）：連接的內層表，在我們從driving table得到具體的一行數據後，在probed table中尋找符合條件的行，所以該表應該爲較大的row source，並且對應連接條件的列上應該有索引。在後面的描述中，一般將該表稱爲連接操作的row source 2.
Concatenated index（組合索引）：一個索引如果由多列構成，那麼就稱爲組合索引，組合索引的第一列爲引導列，只有謂詞中包含引導列時，索引纔可用。
可選擇性：表中某列的不同數值數量/表的總行數如果接近於1，則列的可選擇性爲高。
Oracle訪問數據的存取方法：
Full table scans, FTS(全表掃描)：通過設置db_block_multiblock_read_count可以設置一次IO能讀取的數據塊個數，從而有效減少全表掃描時的IO總次數，也就是通過預讀機制將將要訪問的數據塊預先讀入內存中。只有在全表掃描情況下才能使用多塊讀操作。
Table Access by rowed（通過rowid存取表，rowid lookup）：由於rowid中記錄了行存儲的位置，所以這是oracle存取單行數據的最快方法。
Index scan（索引掃描index lookup）：在索引中，除了存儲每個索引的值外，索引還存儲具有此值的行對應的rowid值，索引掃描分兩步1，掃描索引得到rowid；2，通過 rowid讀取具體數據。每步都是單獨的一次IO，所以如果數據經限制條件過濾後的總量大於原表總行數的5%－10％,則使用索引掃描效率下降很多。而如果結果數據能夠全部在索引中找到，則可以避免第二步操作，從而加快檢索速度。
根據索引類型與where限制條件的不同，有4種類型的索引掃描：
Index unique scan（索引唯一掃描）：存在unique或者primary key的情況下，返回單個rowid數據內容。
Index range scan（索引範圍掃描）：1，在唯一索引上使用了range操作符（>,<,<>,>=,<=,between）；2，在組合索引上，只使用部分列進行查詢；3，對非唯一索引上的列進行的查詢。
Index full scan（索引全掃描）：需要查詢的數據從索引中可以全部得到。
Index fast full scan（索引快速掃描）：與index full scan類似，但是這種方式下不對結果進行排序。
目前爲止，典型的連接類型有3種：
Sort merge join（SMJ排序－合併連接）：首先生產driving table需要的數據，然後對這些數據按照連接操作關聯列進行排序；然後生產probed table需要的數據，然後對這些數據按照與driving table對應的連接操作列進行排序；最後兩邊已經排序的行被放在一起執行合併操作。排序是一個費時、費資源的操作，特別對於大表。所以smj通常不是一個特別有效的連接方法，但是如果driving table和probed table都已經預先排序，則這種連接方法的效率也比較高。
Nested loops（NL嵌套循環）：連接過程就是將driving table和probed table進行一次嵌套循環的過程。就是用driving table的每一行去匹配probed table 的所有行。Nested loops可以先返回已經連接的行，而不必等待所有的連接操作處理完成才返回數據，這可以實現快速的響應時間。
Hash join（哈希連接）：較小的row source被用來構建hash table與bitmap，第二個row source用來被hashed，並與第一個row source生產的hash table進行匹配。以便進行進一步的連接。當被構建的hash table與bitmap能被容納在內存中時，這種連接方式的效率極高。但需要設置合適的hash_area_size參數且只能用於等值連接中。
另外，還有一種連接類型：Cartesian product（笛卡爾積）：表的每一行依次與另外一表的所有行匹配，一般情況下，儘量避免使用。
日常開發活動中，有時候需要對oracle執行計劃進行監控，以此來調優程序和數據庫方面的性能。
常用方法有以下幾種：
一、通過PL/SQL Dev工具
1、直接File->New->Explain Plan Window，在窗口中執行sql可以查看計劃結果。其中，Cost表示cpu的消耗，單位爲n%，Cardinality表示執行的行數，等價Rows。
2、先執行 EXPLAIN PLAN FOR select * from tableA where paraA=1，再 select * from table(DBMS_XPLAN.DISPLAY)便可以看到oracle的執行計劃了，看到的結果和1中的一樣，所以使用工具的時候推薦使用1方法。
注意：PL/SQL Dev工具的Command window中不支持set autotrance on的命令。還有使用工具方法查看計劃看到的信息不全，有些時候我們需要sqlplus的支持。
二、通過sqlplus
1、一般情況都是本機鏈接遠程服務器，所以命令如下：
sqlplus user/pwd@serviceName
此處的serviceName爲tnsnames.ora中定義的命名空間。
2、執行set autotrace on，然後執行sql語句，會列出以下信息：
。。。（省略一些信息）
統計信息
----------------------------------------------------------
1 recursive calls （歸調用次數）
0 db block gets
2 consistent gets
0 physical reads （物理讀——執行SQL的過程中，從硬盤上讀取的數據塊個數）
0 redo size (重做數——執行SQL的過程中，產生的重做日誌的大小)
358 bytes sent via SQL*Net to client
366 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory) 在內存中發生的排序
0 sorts (disk) 在硬盤中發生的排序
1 rows processed
省略部分信息和通過PL/SQL Dev工具查看執行計劃的信息一樣，下面的統計信息是更詳細的。
判斷SQL效率高低不關通過時間來衡量，還應該通過執行SQL執行狀態裏面的邏輯讀的數量
邏輯讀=（db block gets+ consistent gets）
=================================================================================================
基於ORACLE的應用系統很多性能問題，是由應用系統SQL性能低劣引起的，所以，SQL的性能優化很重要，分析與優化SQL的性能我們一般通過查看該SQL的執行計劃，本文就如何看懂執行計劃，以及如何通過分析執行計劃對SQL進行優化做相應說明。
一、什麼是執行計劃（explain plan）
執行計劃：一條查詢語句在ORACLE中的執行過程或訪問路徑的描述。
二、如何查看執行計劃
1: 在PL/SQL下按F5查看執行計劃。第三方工具toad等。
很多人以爲PL/SQL的執行計劃只能看到基數、優化器、耗費等基本信息，其實這個可以在PL/SQL工具裏面設置的。可以看到很多其它信息，如下所示
2: 在SQL*PLUS(PL/SQL的命令窗口和SQL窗口均可)下執行下面步驟
SQL>EXPLAIN PLAN FOR SELECT * FROM SCOTT.EMP; --要解析的SQL腳本 SQL>SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
3: 在SQL*PLUS下(有些命令在PL/SQL下無效)執行如下命令：
SQL>SET TIMING ON --控制顯示執行時間統計數據 SQL>SET AUTOTRACE ON EXPLAIN --這樣設置包含執行計劃、腳本數據輸出，沒有統計信息 SQL>執行需要查看執行計劃的SQL語句 SQL>SET AUTOTRACE OFF --不生成AUTOTRACE報告，這是缺省模式 SQL> SET AUTOTRACE ON --這樣設置包含執行計劃、統計信息、以及腳本數據輸出 SQL>執行需要查看執行計劃的SQL語句 SQL>SET AUTOTRACE OFF SQL> SET AUTOTRACE TRACEONLY --這樣設置會有執行計劃、統計信息，不會有腳本數據輸出 SQL>執行需要查看執行計劃的SQL語句 SQL>SET AUTOTRACE TRACEONLY STAT --這樣設置只包含有統計信息 SQL>執行需要查看執行計劃的SQL語句
SET AUTOT[RACE] {ON | OFF | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]
參考文檔：SQLPlus User’s Guide and Reference Release 11.1
注意：PL/SQL Developer 工具並不完全支持所有的SQL*Plus命令，像SET AUTOTRACE ON 就如此，在PL/SQL Developer工具下執行此命令會報錯
SQL> SET AUTOTRACE ON;
Cannot SET AUTOTRACE
4：SQL_TRACE可以作爲參數在全局啓用，也可以通過命令形式在具體SESSION啓用
4.1 在全局啓用，在參數文件（pfile/spfile)中指定SQL_TRACE =true，在全局啓用SQL_TRACE時會導致所有進程活動被跟蹤，包括後臺進程以及用戶進程，通常會導致比較嚴重的性能問題，所以在生產環境要謹慎使用。
提示：通過在全局啓用SQL_TRACE， 我們可以跟蹤到所有後臺進程的活動，很多在文檔中的抽象說明，通過跟蹤文件的實時變化，我們可以清晰的看到各個進程間的緊密協調。
4.2在當前SESSION級別設置，通過跟蹤當前進程可以發現當前操作的後臺數據庫遞歸活動（這在研究數據庫新特性時尤其有效），研究SQL執行時，發現後臺
錯誤等。
SQL> ALTER SESSION SET SQL_TRACE=TRUE; SQL> SELECT * FROM SCOTT.EMP; SQL> ALTER SESSION SET SQL_TRACE =FALSE;
那麼此時如何查看相關信息？不管你在SQL*PLUS抑或PL/SQL DEVELOPER工具裏面執行上面腳本過後都看不到什麼信息，你可以通過下面腳本查詢到trace日誌信息
SELECT T.VALUE || '/' || LOWER(RTRIM(I.INSTANCE, CHR(0))) || '_ora_' || P.SPID || '.trc' TRACE_FILE_NAME FROM ( SELECT P.SPID FROM V$MYSTAT M, V$SESSION S, V$PROCESS P WHERE M.STATISTIC# =1 AND S.SID = M.SID AND P.ADDR = S.PADDR ) P, ( SELECT T.INSTANCE FROM V$THREAD T, V$PARAMETER V WHERE V.NAME ='thread' AND (V.VALUE = 0 OR T.THREAD# = TO_NUMBER(V.VALUE)) ) I, (SELECT VALUE FROM V$PARAMETER WHERE NAME='user_dump_dest') T
TKPROF的幫助信息如下
TKPROF 選項 選項 說明 TRACEFILE 跟蹤輸出文件的名稱 OUTPUTFILE 已設置格式的文件的名稱 SORT=option 語句的排序順序 PRINT=n 打印前 n 個語句 EXPLAIN=user/password 以指定的用戶名運行 EXPLAIN PLAN INSERT=filename 生成 INSERT 語句 SYS=NO 忽略作爲用戶 sys 運行的遞歸 SQL 語句 AGGREGATE=[Y|N] 如果指定 AGGREGATE = NO TKPROF 不聚集相同 SQL 文本的多個用戶 RECORD=filename 記錄在跟蹤文件中發現的語句 TABLE=schema.tablename 將執行計劃放入指定的表而不是缺省的PLAN_TABLE 可以在操作系統中鍵入 tkprof 以獲得所有可用選項和輸出的列表 注 排序選項有 排序 選項說明 prscnt execnt fchcnt 調用分析執行提取的次數 prscpu execpu fchcpu 分析執行提取所佔用的 CPU 時間 prsela exela fchela 分析執行提取所佔用的時間 prsdsk exedsk fchdsk 分析執行提取期間的磁盤讀取次數 prsqry exeqry fchqry 分析執行提取期間用於持續讀取的緩衝區數 prscu execu fchcu 分析執行提取期間用於當前讀取的緩衝區數 prsmis exemis 分析執行期間庫高速緩存未命中的次數 exerow fchrow 分析執行期間處理的行數 userid 分析遊標的用戶的用戶 ID TKPROF 統計數據 Count: 執行調用數 CPU: CPU 的使用秒數 Elapsed: 總共用去的時間 Disk: 物理讀取次數 Query: 持續讀取的邏輯讀取數 Current: 當前模式下的邏輯讀取數 Rows: 已處理行數 TKPROF 統計信息 統計 含義 Count 分析或執行語句的次數以及爲語句發出的提取調用數 CPU 每個階段的處理時間以秒爲單位如果在共享池中找到該語句對於分析階段爲 0 Elapsed 佔用時間以秒爲單位通常不是非常有用因爲其它進程影響佔用時間 Disk 從數據庫文件讀取的物理數據塊如果該數據被緩衝則該統計可能很低 Query 爲持續讀取檢索的邏輯緩衝區通常用於 SELECT 語句 Current 在當前模式下檢索的邏輯緩衝區通常用於 DML 語句 Rows 外部語句所處理的行對於 SELECT 語句在提取階段顯示它對於 DML 語句在執行階段顯示它 Query 和Current 的總和爲所訪問的邏輯緩衝區的總數
執行下面命令：tkprof D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\TRACE/wgods_ora_3940.trc h:\out.txtoutputfile explain=etl/etl
執行上面命令後，可以查看生成的文本文件
View
Code
TKPROF: Release 10.2.0.1.0 - Production on 星期三 5月 23 16:56:41 2012 Copyright (c) 1982, 2005, Oracle. All rights reserved. Trace file: D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\TRACE/wgods_ora_3940.trc Sort options: default ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ******************************************************************************** ALTER SESSION SET SQL_TRACE = TRUE call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 1 0.00 0.00 0 0 0 0 Misses in library cache during parse: 0 Misses in library cache during execute: 1 Optimizer mode: CHOOSE Parsing user id: 89 (ETL) ******************************************************************************** begin :id := sys.dbms_transaction.local_transaction_id; end; call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 2 0.00 0.00 0 0 0 0 Execute 2 0.00 0.00 0 0 0 2 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.00 0.00 0 0 0 2 Misses in library cache during parse: 0 Optimizer mode: CHOOSE Parsing user id: 89 (ETL) ******************************************************************************** SELECT * FROM SCOTT.EMP call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 2 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 1 0.00 0.00 0 7 0 14 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.00 0.00 0 7 0 14 Misses in library cache during parse: 1 Optimizer mode: CHOOSE Parsing user id: 89 (ETL) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT MODE: CHOOSE 0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'EMP' (TABLE) ******************************************************************************** ALTER SESSION SET SQL_TRACE = FALSE call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 2 0.00 0.00 0 0 0 0 Misses in library cache during parse: 1 Optimizer mode: CHOOSE Parsing user id: 89 (ETL) ******************************************************************************** OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 5 0.00 0.00 0 0 0 0 Execute 5 0.00 0.00 0 0 0 2 Fetch 1 0.00 0.00 0 7 0 14 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 11 0.00 0.00 0 7 0 16 Misses in library cache during parse: 2 Misses in library cache during execute: 1 OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 0 0.00 0.00 0 0 0 0 Misses in library cache during parse: 0 6 user SQL statements in session. 0 internal SQL statements in session. 6 SQL statements in session. 1 statement EXPLAINed in this session. ******************************************************************************** Trace file: D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\TRACE/wgods_ora_3940.trc Trace file compatibility: 10.01.00 Sort options: default 1 session in tracefile. 6 user SQL statements in trace file. 0 internal SQL statements in trace file. 6 SQL statements in trace file. 4 unique SQL statements in trace file. 1 SQL statements EXPLAINed using schema: ETL.prof$plan_table Default table was used. Table was created. Table was dropped. 58 lines in trace file. 0 elapsed seconds in trace file.
4.3跟蹤其它用戶的進程，在很多時候我們需要跟蹤其它用戶的進程，而不是當前用戶，可以通過ORACLE提供的系統包
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION來完成。
例如：
SELECT SID, SERIAL#, USERNAME FROM V$SESSION WHERE USERNAME = 'ETL' EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(61,76,TRUE); EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(61,76,FALSE);
5 利用10046事件
ALTER SESSION SET TRACEFILE_IDENTIFIER = 10046; ALTER SESSION SET EVENTS='10046 trace name context forever, level 8'; SELECT * FROM SCOTT.EMP; ALTER SESSION SET EVENTS ='10046 trace name context off'; 然後你可以用腳本查看追蹤文件的位置 SELECT T.VALUE || '/' || LOWER(RTRIM(I.INSTANCE, CHR(0))) || '_ora_' || P.SPID || '.trc' TRACE_FILE_NAME FROM ( SELECT P.SPID FROM V$MYSTAT M, V$SESSION S, V$PROCESS P WHERE M.STATISTIC# =1 AND S.SID = M.SID AND P.ADDR = S.PADDR ) P, ( SELECT T.INSTANCE FROM V$THREAD T, V$PARAMETER V WHERE V.NAME ='thread' AND (V.VALUE = 0 OR T.THREAD# = TO_NUMBER(V.VALUE)) ) I, (SELECT VALUE FROM V$PARAMETER WHERE NAME='user_dump_dest') T 查詢結果爲wgods_ora_28279.trc文件， 但是去相應目錄卻沒有找到對應的追蹤文件，而是如下trace文件：wgods_ora_28279_10046.trc
6 利用10053事件
有點類似10046，在此略過、
7 系統視圖
通過下面一些系統視圖，你可以看到一些零散的執行計劃的相關信息，有興趣的話可以多去研究一下。
SELECT * FROM V$SQL_PLAN SELECT * FROM V$RSRC_PLAN_CPU_MTH SELECT * FROM V$SQL_PLAN_STATISTICS SELECT * FROM V$SQL_PLAN_STATISTICS_ALL SELECT * FROM V$SQLAREA_PLAN_HASH SELECT * FROM V$RSRC_PLAN_HISTORY
三、看懂執行計劃
1.執行順序
執行順序的原則是：由上至下，從右向左
由上至下：在執行計劃中一般含有多個節點，相同級別(或並列)的節點，靠上的優先執行，靠下的後執行
從右向左：在某個節點下還存在多個子節點，先從最靠右的子節點開始執行。
當然，你在PL/SQL工具中也可以通過它提供的功能來查看執行順序。如下圖所示：
2.執行計劃中字段解釋
SQL>
名詞解釋：
recursive calls 遞歸調用
db block gets 從buffer cache中讀取的block的數量當前請求的塊數目，當前模式塊意思就是在操作中正好提取的塊數目，而不是在一致性讀的情況下而產生的正常情況下，一個查詢提取的塊是在查詢查詢開始的那個時間點上存在的數據庫，當前塊是在這個時候存在數據塊，而不是這個時間點之前或者之後的的數據塊數目。
consistent gets 從buffer cache中讀取的undo數據的block的數量數據請求總數在回滾段Buffer中的數據一致性讀所需要的數據塊，，這裏的概念是在你處理你這個操作的時侯需要在一致性讀狀態上處理多個塊，這些塊產生的主要原因是因爲你在查詢過程中，由於其它會話對數據 塊進行操作，而對所要查詢的塊有了修改，但是由於我們的查詢是在這些修改之前調用的，所要需要對回滾 段中的數據塊的前映像進行查詢，以保證數據的一致性。這樣就產生了一致性讀。
physical reads 物理讀 就是從磁盤上讀取數據塊的數量。其產生的主要原因是：
1：在數據庫高速緩存中不存在這些塊。
2：全表掃描
3：磁盤排序
redo size DML生成的redo的大小
sorts (memory) 在內存執行的排序量
sorts (disk) 在磁盤執行的排序量
2091 bytes sent via SQL*Net to client 從SQL*Net向客戶端發送了2091字節的數據
416 bytes received via SQL*Net from client 客戶端向SQL*Net發送了416字節的數據。
參考文檔：SQLPlus User’s Guide and Reference Release 11.1
db block gets 、 consistent gets 、 physical reads這三者的關係可以概括爲：邏輯讀指的是ORACLE從內存讀到的數據塊塊數量，一般來說是：
consistent gets + db block gets. 當在內存中找不到所需要的數據塊的話，就需要從磁盤中獲取，於是就產生了物理讀。
3.具體內容查看
1> Plan hash Value
這一行是這一條語句的的hash值，我們知道ORACLE對每一條ORACLE語句產生的執行計劃放在SHARE POOL裏面，第一次要經過硬解析，產生hash值。下次再執行時比較hash值，如果相同就不會執行硬解析。
2> COST
COST沒有單位，是一個相對值，是SQL以CBO方式解析執行計劃時，供ORACLE來評估CBO成本，選擇執行計劃用的。沒有明確的含義，但是在對比是就非常有用。
公式：COST=（Single Block I/O COST + MultiBlock I/O Cost + CPU Cost）/ Sreadtim
3> 對上面執行計劃列字段的解釋：
Id: 執行序列，但不是執行的先後順序。執行的先後根據Operation縮進來判斷（採用最右最上最先執行的原則看層次關係，在同一級如果某個動作沒有子ID就最先執行。一般按縮進長度來判斷，縮進最大的最先執行，如果有2行縮進一樣，那麼就先執行上面的。）
Operation：當前操作的內容。
Name：操作對象
Rows：也就是10g版本以前的Cardinality(基數)，Oracle估計當前操作的返回結果集行數。
Bytes：表示執行該步驟後返回的字節數。
Cost（CPU）：表示執行到該步驟的一個執行成本，用於說明SQL執行的代價。
Time：Oracle 估計當前操作的時間。
4.謂詞說明：
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("B"."MGR" IS NOT NULL)
4 - access("A"."EMPNO" = "B"."MGR")
Access: 表示這個謂詞條件的值將會影響數據的訪問路勁（全表掃描還是索引）。
Filter：表示謂詞條件的值不會影響數據的訪問路勁，只起過濾的作用。
在謂詞中主要注意access，要考慮謂詞的條件，使用的訪問路徑是否正確。
5、 動態分析
如果在執行計劃中有如下提示：
Note
------------
-dynamic sampling used for the statement
這提示用戶CBO當前使用的技術，需要用戶在分析計劃時考慮到這些因素。 當出現這個提示，說明當前表使用了動態採樣。我們從而推斷這個表可能沒有做過分析。
這裏會出現兩種情況：
（1） 如果表沒有做過分析，那麼CBO可以通過動態採樣的方式來獲取分析數據，也可以或者正確的執行計劃。
（2） 如果表分析過，但是分析信息過舊，這時CBO就不會在使用動態採樣，而是使用這些舊的分析數據，從而可能導致錯誤的執行計劃。
四、表訪問方式
1.Full Table Scan (FTS) 全表掃描
2.Index Lookup 索引掃描
There are 5 methods of index lookup:
index unique scan --索引唯一掃描
通過唯一索引查找一個數值經常返回單個ROWID，如果存在UNIQUE或PRIMARY KEY約束（它保證了語句只存取單行的話），ORACLE
經常實現唯一性掃描
Method for looking up a single key value via a unique index. always returns a single value, You must supply AT LEAST the leading column of the index to access data via the index.
index range scan --索引局部掃描
Index range scan is a method for accessing a range values of a particular column. AT LEAST the leading column of the index must be supplied to access data via the index. Can be used for range operations (e.g. > < <> >= <= between) .
使用一個索引存取多行數據，在唯一索引上使用索引範圍掃描的典型情況是在謂詞(WHERE 限制條件)中使用了範圍操作符號（如>, < <>, >=, <=,BWTEEN)
index full scan --索引全局掃描
Full index scans are only available in the CBO as otherwise we are unable to determine whether a full scan would be a good idea or not. We choose an index Full Scan when we have statistics that indicate that it is going to be more efficient than a Full table scan and a sort. For example we may do a Full index scan when we do an unbounded scan of an index and want the data to be ordered in the index order.
index fast full scan --索引快速全局掃描，不帶order by情況下常發生
Scans all the block in the index, Rows are not returned in sorted order, Introduced in 7.3 and requires V733_PLANS_ENABLED=TRUE and CBO, may be hinted using INDEX_FFS hint, uses multiblock i/o, can be executed in parallel, can be used to access second column of concatenated indexes. This is because we are selecting all of the index.
index skip scan --索引跳躍掃描，where條件列是非索引的前提情況下常發生
Index skip scan finds rows even if the column is not the leading column of a concatenated index. It skips the first column(s) during the search.
3.Rowid 物理ID掃描
This is the quickest access method available.Oracle retrieves the specified block and extracts the rows it is interested in. --Rowid掃描是最快的訪問數據方式
