記錄一次查詢調優過程

調優過程中使用explain命令檢視執行過程，包括執行時間、掃瞄方式、是否用到索引等，explain 使用**

\timing off

乙個查詢介面被頻繁呼叫，且查詢過程較慢

其次考慮優化業務**

最後考慮是否需要新增快取機制

3.1 優化sql

原始sql，分組查詢每組中seq_id最大的資料，使用in + group by實現

select name, version from yc_test where seq_id in

(select
max(seq_id)
from yc_test group
by name
);

3.1.2 優化後的sql

select a.name, a.version from yc_test a inner

join
(select
max(seq_id)
as seq_id from yc_test group
by name
) b on a.seq_id=b.seq_id;

sql優點

缺點in實現

sql簡單

in會轉換為or再轉為union all，效率較低，如圖多一層迴圈

inner join實現

減少一層迴圈，效率提公升

相比之下sql較複雜

3.2 優化業務**

結合功能的業務場景（可以理解為歷史記錄），走讀**，發現並不是所有資料都需要持久化儲存

優化方案：

熱點資料，可以考慮快取到記憶體中（變數快取），或者儲存資料庫中（redis/memcached）

由於已經對資料量做了控制並結合後期規劃，所以並未新增快取機制

記錄一次系統效能調優過程

問題回顧 問題清單 模組合併過程中各種衝突，各種bean無法正常載入 事件處理效能原來每秒3000 1w左右，現在突然驟降至幾百左右 事件存在丟失現象，而且丟失比較嚴重 發現系統cache一直在不斷的 free m 後發現可餘記憶體幾乎用沒了 剩餘100m左右，其實就差不多是用完了，不會再降低 1....

記一次oracle sql調優過程

這裡兩天都在對一條sql進行調優。該sql並不複雜,類似於 select from some view union all select from some table where datetime d1 and datetime d2 and 底層使用ibatis2.1.6 oracle 10g。...

一次redis調優的過程

記錄一次redis調優的過程，這次事故主要是測試組人員那邊 在給我們測試的時候發現的，有個介面返回資料特別慢，之後我們就去排查問題，結果就發現了是 redis的延遲問題。那究竟是怎麼回事呢？請看下面 介面返回特別慢，檢視了伺服器列印的日誌，發現是redis的問題 根據日誌的提示，找到 中用到redi...