一段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條件有等號的情況下才可以使用。雜湊連線在表的資料量較大，表中沒有合適的索引可用時比巢狀迴圈的效率要高。
總結兩點：
1、這裡看到的執行計畫，只是sql執行前可能的執行方式，實際執行時可能因為軟硬體環境的不同，而有所改變，而且cost高的執行計畫，不一定在實際執行起來，速度就一定差，我們平時需要結合執行計畫，和實際測試的執行時間，來確定乙個執行計畫的好壞。
2、對於表的連線順序，多數情況下使用的是巢狀迴圈，尤其是在索引可用性好的情況下，使用巢狀迴圈式最好的，但當oracle發現需要訪問的資料表較大，索引的成本較高或者沒有合適的索引可用時，會考慮使用雜湊連線，以提高效率。排序合併連線的效能最差，但在存在排序需求，或者存在非等值連線無法使用雜湊連線的情況下，排序合併的效率，也可能比雜湊連線或巢狀迴圈要好。
資料庫效能優化學習
資料庫的效能優化不僅僅是dba的事情，我們程式設計師也是需要了解的。更何況不是每個公司都是有dba的。這就需要我們程式設計師更多的注意。現在的應用基本上都是關聯到對資料庫的操作，對於高併發的應用對資料庫的應用就更為重要。資料庫的優化主要包括資料庫表的設計和sql的優化。以下是學習和應用中的總結 資料...
sql優化,資料庫優化
1.sql的執行順序 from 表名 where 條件 執行順序是從後往前，where條件後面的語句盡可能縮短where 資料執行的範圍。先group by 後order by select 查詢 2.避免過多的聯查，設計合理的表關係 3.遵守常見sql規範，盡可能減少 4.如果表字段過多，經常展示...
sql優化 資料庫優化
資料庫優化 資料庫優化吧我覺應該從硬碟 記憶體和網路頻寬考慮，提高硬碟的讀寫速度，增大頻寬提高吞吐量，增大伺服器記憶體，可以採用讀寫分離，降低單台資料庫的訪問壓力，查詢的時候控制資料量的大小，返回更少資料，減少互動次數，減少cpu及記憶體的開銷，sql優化 如果乙個表中資料量過大我們可以採用橫切割，...