很多朋友都問過我優化SQL的事情。我覺得在我不斷地鼓勵下，很多朋友現在都知道優化SQL之前要先看看執行計劃，也在優化中獲得了很多快樂。但是今天有人問我執行計劃應該怎麼看。我覺得這是個值得寫一寫的東西。
先告訴大家一個原則，看執行計劃的時候，從第一行開始向右下看，一直到最右邊。如果有並列的，那麼先上再下。如果沒並列，右邊的先執行。
閒話少說，先上圖吧：
這是一個簡單的SQL的執行計劃，這個執行計劃告訴我們，id=2的最先執行，然後是id=3的，然後執行id=1的。
首先對test進行一次全表掃描，這一步返回rows=2，CPU的消耗爲2。接下來對test1進行一次全表掃描，這一次返回的rows爲2，CPU的消耗爲3。接下來對這兩個結果進行一次哈希連接（hash join），返回rows=1，這裏的CPU消耗爲6，但是需要注意，這次是我的語句趕寸了，6=2X3，但是哈希連接需要的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。
現在可以總結一下了：執行計劃的準確性（主要指數據返回，數據量大小）由統計信息的準確性決定。