一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表都快取在記憶體，但每次比較
都要從磁碟讀資料和桶裡資料比較
oracle資料庫伺服器io高的分析方案和案例**
我和資料中心的故事-分享批量時快時慢的場景
golang gc 優化思路以及例項分析
乙個即將上線的go 寫的高頻服務，壓測的時候發現 gc 特別高，高到10 15 左右了，本文記錄下優化 gc 的過程和和思路。線上環境1.10.首先，檢視gc 是否有異常，我們可以使用 gctrace 跟蹤實時的gc 執行下面命令可以看到gc 的實時資訊。godebug gctrace 1 go r...
SQL多表優化思路
一 驅動表選擇 左右連線可以指定驅動表，但是inner join無法指定，一般是系統自動判定 1.當使用left join時，左表是驅動表，右表是被驅動表 2.當使用right join時，右表時驅動表，左表是驅動表 3.當使用join時，mysql會選擇資料量比較小的表作為驅動表，大表作為被驅動表...
sql優化例項
1.盡量不生成子表或者將子表的資料量控制到最小 子表只能順序讀取，沒有任何索引 原有sql from select task id,user id from mtcrm task.item where status 0 and is deleted 0 and is archived 0 item ...