一、先聊聊需求
說起這次優化，有點奇葩，從耗時12小時到1分鐘，優化經歷了三次，和自己糾結了n次，看看結果還算安慰。
1.故事背景
恰逢大促東風，不如順勢來個商品破盤，運營、技術、產品聯手一搏提公升商品的豐富度。那這次的問題就從這個需求開始了。。。
2.需求描述：快速提公升商和品的數量，從現有的商品池中撈出符合規則的資料。
3.功能實現：功能很簡單，就是後台通過定時job的方式將疑似商品表的資料進行狀態更新。over~
二、再聊聊方案
1. 第一種方案(標籤：單執行緒執行、無快取、有三方依賴)
（1）方案圖
（2）執行邏輯
類似的小任務也寫過不少，自以為輕車熟路，方案也很順手，順手就是一坨**：
step1：從odps表中將疑似商品資料同步到應用的db表中，做好資料準備
step2：分頁獲取offer資料，每頁必須按照50條資料來執行邏輯。之所以定死這個頁數上線，是由於標第三方hsf的介面的限制，用過的童鞋都知道，效能上限每次最多傳入50條id。先忍一忍，繼續實現功能。
step3：迴圈遍歷每頁，通過第三方介面check是否打上標。然後把已打上標的商品放到乙個list集合中。
step4：將list裡offer依次迴圈回寫狀態
至此coding結束，迫不及待的將任務run起來。又看看表已凌晨1點多，算了，睡上一覺明天收割資料。早上醒來，蛋疼是事情發生了，才跑了100w的資料，並且一直在報超時。異常顯示「hsf timeout：offerqueryserviceexception：***x」，很顯然批量介面不行了，必須優化。
（3）執行結果
本次執行task處理offer數量180w+條，總耗時739分鐘，雖然能順利跑完，但已**。簡單總結下~
本方案滿足了三無條件：
本方案暴露的問題：
2.第二種方案(標籤：多執行緒執行、有快取、有三方依賴)
（1）方案圖
（2）執行邏輯
按照方案一的暴漏問題，逐一優化：
（3）執行結果
本次執行task處理offer數量180w+條，總耗時127分鐘，時間提公升82%，期間無任何異常丟擲，終於可以靜靜的吃瓜了。但又想了想，是不是還有更好的思路可以解決這個問題呢：
本方案也暴露一些問題：
3.第三種方案(標籤：巢狀sql、無三方依賴、批量優化)
（1）方案圖
（2）執行邏輯
從頭開始理解需求，無非就是想把疑似商品找出來，然後回寫狀態。能不能找到替代呼叫三方介面的方案來驗證結果。腦暴一番，果然有。。。
（3）執行結果
本次執行task處理offer數量180w+條，總耗時<<1分鐘，時間提公升100%，期間無任何異常丟擲。
三、小結
回頭想想這次優化的經歷，總結有三點：
一次mysql優化經歷
某日運維突然說無線終端的頻道頁介面訪問量很大，memcache快取扛不過來，導致mysql併發查詢量太大，導致伺服器不停地宕機，只能不停地重啟機器。遺憾的是運維並沒有告訴mysql查詢量具體有多大 無量化，比如一秒多少個查詢 針對這個問題，有同事建議改了mysql memcache的架構，採用red...
一次優化經歷
問題 excel資料匯入，儲存到資料庫中，為了優化查詢效率和其他一些業務需求，需要將資料的一列屬性切分後儲存到redis中，插入資料庫前要保證其中乙個屬性不重複，另外乙個屬性已經在資料庫中。為了將問題描述簡單些，我們假設excel中有兩列資料a和b，其中資料a要保證資料庫中不重複，資料b保證資料庫中...
一次mysql優化經歷
某日運維突然說無線終端的頻道頁介面訪問量非常大，memcache快取扛只是來。導致mysql併發查詢量太大，導致server不停地宕機，僅僅能不停地重新啟動機器。遺憾的是運維並沒有告訴mysql查詢量詳細有多大 無量化，比方一秒多少個查詢 針對這個問題。有同事建議改了mysql memcache的架...