一個效率低下的SQL具有的特點

主要從SQL執行信息（v$sql,gv$sql...)和SQL執行計劃(v$sql_plan,gv$sql_plan,v$sql_plan_statistics_all...)的特點上來討論，比如：
1.OLTP環境下，v$sql上executions>1000的，單次elapsed_time>3s,就認爲可能SQL屬於高耗SQL，需要關注。。。
2.執行計劃有笛卡爾積運算的，需要關注。。。
3.OLTP環境下，SORT MERGE JOIN的需要關注。。。
4.謂詞出現顯示函數運算或自動函數索引或數學運算，運算在索引列上的需要關注。。。
5.執行計劃有FILTER多子操作，且父操作card估算超過1000的。。。需要關注



1. 索引建立的不合理。
2.N久沒有收集統計信息。
3.一個表的名字出現多次，造成對錶的多次 scan 。

btree index 出現bitmap conversion

1. SQL文本比較長，一眼看上去比較複雜
2. 沒有恰當地使用INDEX
3. （老版中）統計信息收集不及時，與實際差異較大
4. 涉及的表沒有進行有效的段空間維護，使得數據實際小，而高水位很高
5. 對其調整是要用到執行計劃
6. 複雜的SQL，DBA會做等價改寫

1.SQL裏面嵌入自定義函數反覆執行。
2.動態SQL使用硬解析，沒有使用綁定變量。

1：同一個表關聯了多次，看看是否可能消除不必要的連接。有的時候是因爲使用了視圖所導致的，這點我一般會看一下。
2：過多層的NL。要看看數據返回量與優化器的評估量之間的差別。

1、統計信息沒問題時，且cost >100,0000，可能業務邏輯有問題， 需要重視；
2、cost < 1000 且 executions > 60s 的， 可能執行計劃有問題， 需要重視；
3、SQL 執行計劃包括 ‘PARTITION RANGE ALL’  沒加分區條件的， 需要重視；【博客：http://blog.itpub.net/28602568/viewspace-1250423/】
4、一個SQL的執行計劃出現了5次全掃，可能遺漏可能加的索引條件，需要重視；
5、執行計劃出現('MERGE JOIN CARTESIAN','FILTER')，可能情況（統計信息問題、少關聯條件