執行計劃詳解

執行計劃的檢視經典版

 

 

 

上面的SQL*Net roundtrips to/from client ---表示透過網路（SQL*Net）往返（round）幾次的意思；

上面這句表示伺服器到客戶端傳送了多少位元組。

 

上面這句表示客戶端到伺服器端傳送了多少位元組。

 

redo size----表示產生的日誌多少（普通的查詢是不產生日誌的，但是有些特殊查詢也是產生日誌的）。

 

 

上面表示的是遞迴呼叫。oracle在執行select count(*) from tt這條sql語句時，oracle還要執行其他的sql，用來解釋select count(*) from tt這條sql（我們寫的sql語句只是一個文字的，但oracle需要對你寫的sql語句進行編譯，使之成為計算機識別的符號才能執行）。

oracle是怎麼解釋你寫的sql語句呢？其實oracle是透過查資料字典、後設資料來解釋的，這時是需要cpu資源：

1)      判斷物件（表）是否存在

2)      判斷是否許可權訪問

3)      判斷sql是否與語法錯誤

上面這三條sql語句的解釋都稱之為遞迴呼叫。

 

 

 

上面的consistent gets和physical reads是真正執行sql語句消耗的資源。

 

其中，

consistent gets，表示邏輯讀，即從記憶體中訪問資料塊的次數。如果一個資料塊訪問了9087次，那麼邏輯讀就是9087；如果每一個資料塊只訪問過一次，但訪問了9087個塊，那麼邏輯讀也是9087。

其實我們最佳化sql語句的目的就是降低consistent gets。

 

physical reads，表示物理讀。說明記憶體太小了，需要訪問的資料塊完全沒有在記憶體中保留下來，還得需要從磁碟來讀取所需要的資料塊。這意味這條sql語句訪問時，data buffer 空間不夠，不能把這個表涉及到資料塊全部放在data buffer cache中來。

執行計劃檢視的規則：

1、首先檢視縮排最靠右側的執行計劃 ------&gt最先執行

2、同等級縮排的執行計劃，從上倒下執行

3、父子關係，如果有孩子先執行孩子，在執行父親

 

執行計劃的案例分析

 

第一個案例

上面的sort aggregate是排序聚合的意思，即表示的就是count()這個函式的動作。

select statement表示把最後的結果返回給使用者。

 

第二個案例

 

從上圖可看出，此計劃是一個二叉樹，有兩個分支，分別為上圖的1和2

 

小知識：一個表的大小由哪些因素來決定呢？

假設一個表很大，可能是這個表有很多欄位，每個欄位都很寬導致的表大；另一個可能是這個表的資料量很大。

 

小知識：一個表裡面的欄位不能太多，oracle允許一個表裡面最多能達到一千個欄位。但是最好一張表不要超過256個欄位。

 

小知識：我們在修改一個欄位的資料時，oracle會把這個欄位所在的行鎖住，其他人就不再能修改這行的所有欄位，直到這個人把行鎖釋放為止。所以一個表不要把欄位設定的太多，否則行鎖鎖表的面積就會很大，從而導致資料庫瓶頸。

 

下圖演示的就是一個人在修改某一行的一個欄位的值時，這行資料就被鎖住，別人就操作不了這行資料了。所以如果一個表的欄位越多，那麼發生行鎖的機率也就越大。因為可能很多人都要修改這行資料的不同欄位，從而導致行鎖。

 

 

 

檢視執行計劃的步驟：

1）

檢視縮排最靠右側的執行計劃是6和7

2）

執行計劃同一縮排計劃，按照從上倒下的順序執行，執行順序為上圖所示，先執行1在執行2

 

3）

按照執行計劃規則，先執行孩子，在執行父親，上圖所示：6 、7是5的孩子

所以先執行6和7再執行5，執行順序為6、7、5

 

4）

 

上圖所示 5和 8 是同一等級縮排，先執行5 再執行8。  3）說明5已經執行完

執行8, 8為父親，下面還有孩子，所以先執行孩子 9，再執行8

執行順序為 6、7、5、9、8

 

5）

上圖所示：6、7、5、9、8已經執行完。4是6、7、5、9、8的父親，孩子執行完，執行父親，所以在執行4，順序為 6、7、5、9、8、4

6）

 

 

上圖所示：4和10 是同一等級縮排，4執行完成，在執行10

 

7）

 

上圖所示：10 是11、12的父親，所以先執行孩子，11 和12 是同一等級，按照從上倒下順序執行，先執行11，在執行12 ，但是12又是13的父親，所以先執行13，在執行12

 

以上順序為：6、7、5、9、8、4、11、13、12、10

 

 

上圖所示：按照執行計劃原則，縮排最靠右側的先執行，執行為 3、2、1

 

 

綜上圖解：

執行計劃順序為

6、7、5、9、8、4、11、13、12、10、3、2、1、0

綜上所述圖解：

下面我們就可以將執行計劃畫成一個二叉樹。

 

 

hash value

 

 

上面表示set autot trace顯示的執行計劃，其實是從v$sql_plan裡面構造出來的。

v$sql_plan檢視中，上面這兩列可以輕鬆的看出父子關係。