MySql單表最大8000W+ 之數據庫遇瓶頸記

前言

昨晚救火到兩三點，早上七點多醒來，朦朧中醒來發現電腦還開着，趕忙爬起來看昨晚執行的SQL命令結果。因爲昨晚升級了阿里雲的RDS，等了將近兩個小時 還在 升降級中，早上阿里雲那邊回覆升級過程當中出現異常，正在加緊處理。。。有點蛋疼

 

項目介紹

這個項目主要分爲WEB、WEB-Manager、WEB-API、APP（ANDROID、IOS） 。

開發語言主要是ASP.NET 

數據庫MySql

架構採用了ASP.NET +EF+ORM   Unity依賴注入 採用了DDD的部分實踐 

ORM使用的是AutoMapper

使用了Redis緩存

Log4net記錄文件日誌，剛開始使用Mongodb記錄日誌，用了一段時候後取消了。

WEB端使用了angularjs    

API層經過JSON數據與APP進行交互，用戶狀態經過access_token進行傳遞

數據庫層目前是基於倉儲（Repositor）模式實現的

剛開始項目急於上線多數採用Linq +lambda 的查詢方式，在實踐過程當中發現變態的業務調整和快速的請求響應，將其複雜的查詢改爲了原生SQL，經過Context.DataBase.SqlQuery  執行

 

其餘的技術就不一一介紹了

目前訪問量較大的是APP端， 最大併發 1300+

主要是API的壓力比較大，日均 100W+ 請求，API 目前 部署在Windwos server 2012上，  接口在50個以上

數據庫使用的是阿里雲的單機MySql  RDS 5.6 版本，10盒12G，鏈接數2000，iops 6000  

目前 單表最大是8000W+數據。物理文件300G，APIlog日均100W+，API與業務系統徹底獨立，除了DBLog日誌還有Log4g.net生成的文件日誌。

目前採用的是阿里雲的負載，一主一從  購買的阿里雲負載      兩臺應用均爲 8盒16G ，10M帶寬 ，資源文件上了CDN。

主的上面部署了WEB端和WEB管理後臺，從的上面只有API。

數據庫遇瓶頸

        最近用戶量突破10+以上，最大併發1300+  從前天晚上開始數據庫CPU居高不下，一時達到100%臨界點，致使不少SQL命令執行發生錯誤，連接拒絕。阿里雲的報警短信也隨之而來，隨即我停掉了IIS應用，由於不中止應用MySql數據庫很難復甦，大概過了5分鐘以後數據庫恢復正常，而後再開啓IIS應用。蛋疼的是阿里雲的負載健康檢查也提示異常，但有點不解的是健康狀態顯示異常，請求仍然在繼續分發，非常不解。立馬我將IIS 應用程序池資源回收，中止而後再重啓，這裏給個提示  重啓IIS應用程序池的時候最好先中止掉IIS應用，而後再重啓IIS應用程序池，否則訪問量大的狀況下很難起起來。過了幾分鐘以後負載上的健康檢查顯示正常。

       上阿里雲後來看了下各個監控指標，顯示流量從前一個小時開始 忽然猛增，我覺得是有攻擊，但跟蹤了幾個鏈接發現是正常請求，但360的防護助手顯示確實有幾個攻擊，但那幾個請求根本不足以拉跨數據庫，大概也就幾十個請求，   幾個簡單的  XSS攻擊 這裏貼下：攻擊的數量不是太多，但主要攻擊的內容和參數就這個幾種類型

url/'%22/%3E%3C/script%3E%3Cscript%3Ealert()%3C/script%3E
url/'%22+onmouseover=alert()+d='%22

url/matrix_callback.php    

url/index.php?option=com_fields&view=fields&layout=modal&list%5Bfullordering%5D=updatexml(0x3a,concat(1,md5(233)),1)

後來發現是數據庫遇到危機了，CPU幾度達到了100%，活躍鏈接數和非活躍鏈接數都比平時都要高不少。目前數據庫中有一張最大的表超8000W條數據，超300W以上的也有十幾張，是查詢拖垮了數據庫，平時開發的時候咱們都是要求查詢類的SQL要求0.03秒以內完成。但涉及到這幾張大表的查詢咱們設定到0.5秒以內返回。今天確定是查過0.5秒了，

我查了下阿里雲控制檯的慢SQL日誌，眼下系統運行還稍微正常，就拿那些慢SQL 一個一個的優化，不能立馬發版，也就是不能改寫SQL代碼，只能從索引上進行優化了。就這樣把慢SQL逐一過了一遍，大約有20多個  超2秒執行的，最慢的達到了10秒，最大的解析行數達到了10W行以上，哎 應該是下面的兄弟寫sql不嚴謹，不然不會出現解析行數超10W+的，但兄弟挖的坑 我哭着也要去填。就這樣用explain 調整索引的方式逐一過了一遍，以前經過表空間已經作過一次優化了。

到昨晚又到了高併發的時候，數據庫又報警了，還好只是報警沒有給我crash掉。與客戶那邊溝通下來，決定進行數據庫擴容。如今擴容到了16盒64G 鏈接數14000 iops16000。

增長了一個應用幾點，如今是一主兩從

應該能撐一段時間了

 

接下來須要着手上讀寫分離， 針對比較大的表進行拆分，代碼和數據庫繼續優化。儘可能作到最優。

再下來着手上分佈式   由於架構的演變是根據市場營銷狀況而定，不能走太前更不能走到市場的後面

週末比較累 寫的比較簡短，有時間再續