如何檢視執行計畫以及執行計畫的準

如何檢視執行計畫以及執行計畫的準確性

很多朋友都問過我優化sql的事情。我覺得在我不斷地鼓勵下，很多朋友現在都知道優化sql之前要先看看執行計畫，也在優化中獲得了很多快樂。但是今天有人問我執行計畫應該怎麼看。我覺得這是個值得寫一寫的東西。

先告訴大家乙個原則，看執行計畫的時候，從第一行開始向右下看，一直到最右邊。如果有並列的，那麼先上再下。如果沒並列，右邊的先執行。

閒話少說，先上圖吧：

這是乙個簡單的sql的執行計畫，這個執行計畫告訴我們，id=2的最先執行，然後是id=3的，然後執行id=1的。

對test1進行一次全表掃瞄，這一步返回rows=2，cpu的消耗為3。對test進行一次全表掃瞄，這一次返回的rows為1，cpu的消耗為2。接下來對這兩個結果進行一次雜湊連線（hash join），返回rows=1，這裡的cpu消耗為6。

但是需要注意，這次是我的語句趕巧了，6=2*3，但是雜湊連線需要的cpu cost絕對不會恰恰是之前執行的操作的cpu cost之積，特別說明一下。

至此，我們的oracle對這個語句的執行計畫結束。

這個執行計畫是怎麼得到的？既然是計畫，那麼絕對不是把這個語句先執行一遍，然後把這個計算出來，那樣的話這個執行計畫就成了事後諸葛亮了。這個執行計畫是oracle根據統計資訊得到的。那麼這個執行計畫就有可能不准，請大家看看我的語句以及執行出來的結果：

select a.ser_id, b.owner from test a, test1 b where a.area_id = b.owner;

結果如圖：

怎麼樣？絕對不是6行那麼點點東西吧？這個表的統計資訊看來非常非常舊了。於是我對兩個表重新進行統計：

analyze table test compute statistics;

analyze table test1 compute statistics;

然後再看看執行計畫：

腫麼樣，這樣就不是那麼小了吧？test有12m行的返回。test1的owner欄位只有兩條記錄：911和290。那麼對應的test中area_id=290/911的有多少條記錄呢？count一下：8485760，那麼為什麼是12m行呢？因為是全表掃瞄：

select count(*)/1024/1024 from test;

結果就是12

現在可以總結一下了：執行計畫的準確性（主要指資料返回，資料量大小）由統計資訊的準確性決定。

**：