1、起因
某日下午18:40開始，接收到滕訊雲短信報警，顯示數據庫CPU使用率已超過100%，同時慢查詢日志的條數有1500條左右。
正常情況下：CPU使用率為30%-40%之間，慢查詢日志條數為0.
2、查詢原因
因接收短信時，正好在回家的路上，無法處理，所以只能到家再處理。
在路上的時候，接收了幾次恢復短信和再次異常短信。說明問題是一時有，一時恢復。
到家后，登錄騰訊雲數據庫控制台，查詢監控，發現CPU使用率確實為145%，且持續時間是20分鍾。
18:40-19:00
19:20-19:40
然后，我登錄騰訊雲的phpMyAdmin控制台，想嘗試看下有哪些查詢正在發生。於是執行了show processlist命令，不巧的是，我執行命令的時候，高峰期已過，看不到任何查詢。
於是，我下載了18:00-19:00之間的慢查詢日志文件，想從中找到問題。下載之后，發現第一條慢查詢開始的時間正是18:41分鍾。且查看整個文件，發現都是同一條SQL語句，查詢的是同一張表，且uid始終是同一個。
由於我對於業務不是很熟悉，於是我將這些SQL語句截圖發給了開發人員。開發人員在看到SQL語句后，找到了相應的代碼位置，並告訴了我，引發該SQL查詢的原因是請求了某個地址，/account/...。
然后我下載了負載均衡的訪問日志，只下載了18:00-19:00時間段的。我根據開發人員提供的URI，查詢日志，發現真有記錄。
然后，我嘗試過濾該日志，以確定訪問地址。我首先過濾整個日志，以統計/account/...出現的數量。發現數量為7900條。為了得知這7900條是否為18:00-19:00出現的，於是我單獨過濾了日志中帶"18:4"字符串的數量以及"19:5"字符串的數量。發現兩者加起來的數量為7600條。說明這7900條請求確實是從18:40-19:00這個時間段開始發起的。
且很明顯的是，所有請求來自同一個IP地址。原因很明顯了，就是某個白痴在發起異常請求。
3、處理辦法
首先在負載均衡的防火牆上限制了該IP的訪問。然后開發人員也加上了CSRF。