SQL優化例項-思路分析

一SQL優化思路
一個真實具體的SQL優化思路
一般都看預估的執行計劃，比如遇到一個sql執行計劃很長，很複雜，從計劃中沒有看到返回行數多，cost高或連線方式錯誤的地方，沒有明顯瓶頸，但整體邏輯讀很高，執行很慢。這時就可以去看真實的執行計劃，並檢視真實計劃裡邏輯讀cr最多的步驟。可以做個10046。根據邏輯讀最多的步驟判斷對應連線方式，比如這裡nest loop 的cr最大，且對應倆大結果集。顯然有問題。於是再根據預估的執行計劃判斷倆表的連線方式。預估計劃是164 ：1結果集，那根據對應查詢條件，發現查詢條件上使用了trunc函式，導致優化器用預設選擇度估計返回行數較少就用全表掃描做驅動表了。

二 AWR分析思路
 根據awr分析
1 資料庫IO 大 概要指標，物理讀
負載很高，概要中發現物理讀很高；進一步發現等待事件中跟io等待相關的事件很多；
於是先去wait class小結看到IO等待佔比到70%以上，再看 time model中再發現sql執行佔db time比例很大，可見總體sql執行時間長，IO等待佔用大量消耗，說明是大量IO等待高的sql導致物理讀，於是就根據具體哪個維度檢視sql效能，綜上判斷跟sql 的io等待有關所以檢視按io wait排序的top sql

2 dbcpu 消耗大 概要指標，dbcpu
dbcpu指標值和邏輯cpu近似 ，判斷小號在dbcpu的時間多，進一步根據host指標判斷busy cpu比例也很大，判斷dbcpu上執行時間很長，
首先根據cpu維度查詢top sql， 找出慢sql優化。優化的sql是查詢條件裡使用了or，這點可根據執行計劃裡的實際時間判斷具體慢的計劃步驟，
然後對sql改寫成union方式，具體union還是union all 根據select查詢出的欄位是否有唯一所以判斷查詢欄位中沒有重複資料，所以用
union all不會排重，也不會排序，簡單合併結果後就返回

3 概要指標 redo size
根據redo size 可以判斷是redo日誌太小，還是dml操作過多
如果redo size到 2M/s 那一分鐘120M 20分鐘就是2400M，而現在一個日誌檔案50M ，50M/2M 半分鐘就慢了，所以可以跑個ADDM ，
根據建議把redoSize設定到2G。
參考 效能調優之redo切換頻率

4 邏輯讀和物理讀幾乎一致
判讀是直接繞過SGA，讀資料到PGA了，等待事件發現有direct path read，根據問題現象發現使用者用8條sql做並行測試，因此db判斷
每個程式各讀各的不在共享一個SGA，其他記憶體裡讀資料，因此效能變慢
也有類似邏輯讀和物理讀差不多的時候，但那就是邏輯讀慢，執行時間長，且大部分時間在db cpu上，跟HASH 連線演算法有關，
使某個桶內的資料太過多，早成每個塊上的資料每次都要在桶內比較很長時間，造成邏輯讀很低，hash表都快取在記憶體，但每次比較
都要從磁碟讀資料和桶裡資料比較
http://blog.itpub.net/26736162/viewspace-2137141/  Oracle資料庫伺服器IO高的分析方案和案例探討
http://www.talkwithtrend.com/Article/177951 我和資料中心的故事-分享批量時快時慢的場景

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/750077/viewspace-2141158/，如需轉載，請註明出處，否則將追究法律責任。