雙11 mysql db 性能 掃雷

 雙11發生了一個惡夢，平臺系統流單出現了新低，遠遠達不到預期流單值，從11月10日11:30開始，整個團隊都動起來，下游系統也在喊：單少，電話開始響起，進入精神緊張的狀態。技術人員開始排查問題緣由，經過zabbix查看DB、web服務器的運行狀態，查看系統運行日誌，均發現不了什麼緣由引發的。

 當天晚上操做內容：

 一、業務降級處理

 ①中止部分不重要的定時任務，不強佔資源，調整後，有微小的效果

 ②中止全部定時任務，單倉跑，調整後，性能有提高，但仍是慢

 二、緊急擴容

 ①web服務器擴容，把業務重的定時任務抽出來單獨跑，性能有提高，流單效率相對提升一點，但仍是不知足下游

 ②osp服務器擴容，把服務化接口擴展3臺服務器，性能有提高，基本知足下游的需求。

 就這樣一堆人排查了一夜，可是並無發現系統忽然慢的緣由。

 

 次日，開始開會覆盤，討論從哪些方面入手解決問題，安排人從各個方面入手去排查，在有限的時間內作了如下幾個事情：

 一、安排QA對系統進行壓測，測試系統處理能力

 二、檢查程序處理邏輯是否存在不合理的地方。

 三、梳理db的慢SQL、歸檔計劃

 四、安排時間再作一次線上壓測

 【第4點就限制了咱們要在某個時間點裏要發現問題，並處理】

 緊張感覆蓋在整個團隊中，但咱們須要堅持，爭分奪秒，務必要把這個大坑填上.....而我在裏面處理第3點，在這裏就講講個人處理過程：

 一、check db tps/qps

 DB的TPS最高峯達到1.5W，QPS達到3K，這基本是DB的最大效能，沒有呈現持續上升的趨勢，雙11期間數據量比平時大，在預期結果以內。但隨着業務增加，單量數據增多，面臨着DB分庫的必要性，減小單個db的tps和qps量，分散壓力。

 二、check db cpu

 cpu使用不超過5%，無風險。

 三、check db 與web服務器的當前鏈接數

 show variables like 'max_connections';  --查看db設置的最大鏈接數

 show global status like 'Max_used_connections';  --查看db過去的最大鏈接數

 發現天天服務器的鏈接數偏高，初步懷疑是鏈接泄露的問題，檢查編寫的代碼，使用的開源組件是否存在鏈接泄露。

 優化點：

 ①加大程序代碼鏈接池初始化的量

 ②調整代碼爲線程安全的

 參考文章：http://blog.csdn.net/iquicksandi/article/details/7970706

 四、check db 慢sql

 show variables like '%long_query_time%'; -- 查看db超過設置的時間爲慢SQL，通常：100ms

 show variables like '%slow_query_log%'; --查看DB慢SQL日誌是否開啓

 show variables like '%slow_query_log_file%'; --慢SQL日誌文件路徑

 因爲沒有權限查看生產DB，找DBA統計全部的慢SQL進行逐條分析，參考維度：

 ①檢查where後的查詢條件是否有建索引

 ②索引是否正常使用，例如varchar類型，查詢的時候值須要加單引號，bigint類型，查詢的時候不能加單引號，不然db執行的時候沒有使用到索引

 ③優化索引，對於多條件查詢可使用組合索引

 ④結合代碼分析，優化代碼使用索引是否正常

 分析後，增長了索引，對代碼進行了優化，還須要用explain查看執行計劃，保證索引被用上

 五、數據歸檔

 正常來講，數量越少，執行速度越快，根據本身系統的業務，梳理業務數據保留的天數，較少無用數據保留在操做表。但也存在當數據量達到必定量的時候，索引會失效，這個就要考慮索引建得是否合理。對數據歸檔後，慢SQL也明顯減小。

 

 通過一個星期的排查，基本把代碼和模型都查了個遍，從總體進行優化，中間經過迭代版本，重複排查，過程是艱辛的，結果是可喜的，達到性能要求，oh,ye。

 但願你們喜歡這篇文章，請指出不合理，或者有更好的方法和工具排查，後續補充一、二、4點的排查過程，謝謝你們。

 做者：godsfer