一段sql**寫好以後，可以通過檢視sql的執行計畫，初步**該sql在執行時的效能好壞，尤其是在發現某個sql語句的效率較差時，我們可以通過檢視執行計畫，分析出該sql**的問題所在。
1、 開啟熟悉的檢視工具：pl/sql developer。
在pl/sql developer中寫好一段sql**後，按f5，pl/sql developer會自動開啟執行計畫視窗，顯示該sql的執行計畫。
2、 檢視總cost，獲得資源耗費的總體印象
一般而言，執行計畫第一行所對應的cost(即成本耗費)值，反應了執行這段sql的總體估計成本，單看這個總成本沒有實際意義，但可以拿它與相同邏輯不同執行計畫的sql的總體cost進行比較，通常cost低的執行計畫要好一些。
3、 按照從左至右，從上至下的方法，了解執行計畫的執行步驟
執行計畫按照層次逐步縮排，從左至右看，縮排最多的那一步，最先執行，如果縮排量相同，則按照從上而下的方法判斷執行順序，可粗略認為上面的步驟優先執行。每乙個執行步驟都有對應的cost,可從單步cost的高低，以及單步的估計結果集（對應rows/基數），來分析表的訪問方式，連線順序以及連線方式是否合理。
4、 分析表的訪問方式
表的訪問方式主要是兩種：全表掃瞄（table access full）和索引掃瞄(index scan)，如果表上存在選擇性很好的索引，卻走了全表掃瞄，而且是大表的全表掃瞄，就說明表的訪問方式可能存在問題；若大表上沒有合適的索引而走了全表掃瞄，就需要分析能否建立索引，或者是否能選擇更合適的表連線方式和連線順序以提高效率。
5、 分析表的連線方式和連線順序
表的連線順序：就是以哪張表作為驅動表來連線其他表的先後訪問順序。
表的連線方式：簡單來講，就是兩個表獲得滿足條件的資料時的連線過程。主要有三種表連線方式，巢狀迴圈（nested loops）、雜湊連線（hash join）和排序-合併連線（sort merge join）。我們常見得是巢狀迴圈和雜湊連線。
巢狀迴圈：最適用也是最簡單的連線方式。類似於用兩層迴圈處理兩個游標，外層游標稱作驅動表，
oracle檢索驅動表的資料，一條一條的代入內層游標，查詢滿足where條件的所有資料，因此內層游標表中可用索引的選擇性越好，巢狀迴圈連線的效能就越高。
雜湊連線：先將驅動表的資料按照條件欄位以雜湊的方式放入記憶體，然後在記憶體中匹配滿足條件的行。雜湊連線需要有合適的記憶體，而且必須在cbo優化模式下，連線兩表的where條件有等號的情況下才可以使用。雜湊連線在表的資料量較大，表中沒有合適的索引可用時比巢狀迴圈的效率要高。
6、 請核心技術組協助分析 www.2cto.com
以上步驟可以協助我們初步分析sql效能問題，如果遇到連線表太多，執行計畫過於複雜，可聯絡核心技術組共同討論，一起尋找更合適的sql寫法或更恰當的索引建立方法
總結兩點：
1、這裡看到的執行計畫，只是sql執行前可能的執行方式，實際執行時可能因為軟硬體環境的不同，而有所改變，而且cost高的執行計畫，不一定在實際執行起來，速度就一定差，我們平時需要結合執行計畫，和實際測試的執行時間，來確定乙個執行計畫的好壞。
2、對於表的連線順序，多數情況下使用的是巢狀迴圈，尤其是在索引可用性好的情況下，使用巢狀迴圈式最好的，但當oracle發現需要訪問的資料表較大，索引的成本較高或者沒有合適的索引可用時，會考慮使用雜湊連線，以提高效率。排序合併連線的效能最差，但在存在排序需求，或者存在非等值連線無法使用雜湊連線的情況下，排序合併的效率，也可能比雜湊連線或巢狀迴圈要好。
附i：幾種主要表連線的比較
PLSQL查詢執行計畫
一般優化途徑 如果能通過修改語句優化，比如查詢條件或執行順序，sql改不了，可以通過增加索引來解決，增加索引還不行，那就要考慮實現方式是否有問題了 一段sql 寫好以後，可以通過檢視sql的執行計畫，初步 該sql在執行時的效能好壞，尤其是在發現某個sql語句的效率較差時，我們可以通過檢視執行計畫，...
MS Project 中如何設定計畫進行狀態燈。
前兩天被要求在ms project中設定乙個計畫狀態燈，好一目了然的來看某個計畫的目前的情況如何。大概的步驟如下 在工具中，呼叫企業模板 在工具中，設定乙個自定義企業域 將這個列設定公式 設定這個列為顯示模式，定義顯示的規則 作了個教程檔案，沒有放上來，需要的可以發郵件給我。狀態 顯示燈 返回值 暫...
用PL SQL檢視SQL語句執行計畫
一般通過很多任務具可以看pl sql的執行計畫來分析語句效能。這裡介紹通過pl sql檢視sql執行計畫的幾種方法 方法一.set autotrace on 然後當執行你的sql語句的時候，執行計畫自動顯示出來。不想看執行計畫了，set autotrace off 方法二.執行語句 explain ...