很多朋友都問過我優化SQL的事情。我覺得在我不斷地鼓勵下，很多朋友現在都知道優化SQL之前要先看看執行計划，也在優化中獲得了很多快樂。但是今天有人問我執行計划應該怎么看。我覺得這是個值得寫一寫的東西。
2012年6月21日增加：
我下面的執行計划是怎么打印出來的，很多朋友還是不知道。其實語句只有三條：
explain plan for 你要查看的SQL語句; commit; select * from table(dbms_xplan.display);
-----分割線----------------------------------
先告訴大家一個原則，看執行計划的時候，從第一行開始向右下看，一直到最右邊。如果有並列的，那么先上再下。如果沒並列，右邊的先執行。
閑話少說，先上圖吧：
這是一個簡單的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。
現在可以總結一下了：執行計划的准確性（主要指數據返回，數據量大小）由統計信息的准確性決定。