最近常有網友問起耗能分析的思路，有時轉來轉去的，較浪費時間，這裏小結下；結合實例講解；
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
1. 如下這條SQL，它有沒有什麼問題，能不能優化？
2.很簡單看下計劃即可（這裏有些人會問到有些跑很久纔會出結果，所以你可以跑上10來S，然後ctrl+c中斷看一個時間段即可）
如下我們可以看到，這條SQL存在兩個表的全表掃描，時間上還是很快的（0.02），邏輯讀2079,結合predicate information信息
自然會產生一個疑問，object_id有無索引？是否適合建索引？從最後的NOTE中也可以意識到，這條SQL中的涉及對象存在沒有統計
信息的情況；
3.運行sosi命令也可以分別看到T1,T2類似的情況，沒有統計信息；
4.進行統計收集，當然如果生產上時候不能做，你也可以通過select count( distinct object_id) from t1 ; 這樣的方式，只是比較麻煩；
5.通過查看可以看到全錶行數72624，object_id的唯一值的不重複數爲72624-4=72620(扣去空值4，可見選擇率相當的好）；
6.T2的表也類似
7.接下來就順理成章的創建索引，然後查看計劃可以看到，時間變爲0.01,邏輯讀也從之前的2079->6；
SQL> create index idx_t1_id on t1(object_id);
SQL> create index idx_t2_id on t2(object_id);
SQL>
8.當然以上只是一個很簡單的例子，在實際的生產環境中會更復雜；
比如：
1.有些變量很快，有些變量又存在很慢 解決方法：=>建立直方圖 or 綁定計劃（這個計劃是通用的) ?
2.有些根據它SQL的寫法和需要就非得全表掃描一個幾十萬的表 =>解決辦法：減少頻率，分區，修改業務邏輯等
3.有些是系統的參數要調整：如一個習慣使用parallel的HINT的系統，parallel_max_servers卻設置的過小，那麼你就需要結合CPU和IO進行調整；
4.有些是模型問題，比如明明物化視圖能解決的，你非要用普通視圖，那執行的速度上是可想而知的；
5.有些是SQL的寫法上引起的，這種的解決要結合業務進行調整等價改寫即可；
6.有些是執行頻率過大，執行的時間段可以調整的也可以根據實際情況進行相應的調整；
7.還有些是執行計劃上的改變引起的，那麼你可以採用暫時固定計劃的方式解決(baseline,sql profile);
8. and other ........