記錄惡意SQL註入引發的RDS只讀資料庫CPU飈100%

前言: 在廣州這座城市下著小雨的晚上，我正在廚房洗著碗，突然手機有來電，脫下手套，一看是來自阿裡雲的告警電話。打開飛書查看告警內容，發現某個業務的RDS只讀實例CPU飈到100%，下意識覺得是不是有慢查詢導致，想著不會有啥問題，上去kill慢查就好了，結果發現是大問題....
一、發現問題

  2024年3月10號 21:22分左右，手機響起來自阿裡雲的告警通知，確定了是阿裡雲RDS報警,MySQL有一波連接數進來，資料庫CPU瞬間100%，MySQL連接數也觸發告警，10分鐘不到有35000多條慢日誌，同時阿裡雲只讀庫進行了實例主備切換（故障切換）
問題影響了線上用戶登錄和充值，當時工作群運營反饋問題，技術這邊也關註起來。

二、分析造成原因

業務運行的RDS是1主4只讀的架構，然後開啟資料庫代理，讀寫分離。
一開始以為是管理後臺有人在查數據，全表掃描或者查看日期時間範圍很長導致只讀庫有慢查，因為之前出現過這種情況，結果看到控制台幾萬條慢查詢。影響我判斷的告警來了，只讀實例出現故障進行主備切換，以為是實例出現問題，我立馬去找阿裡雲客服問實例是否有問題，為什麼會主備切換了。結果技術客服回答，是因為有一波連接數進來，慢查裡面執行SQL有掃描行數很大的可以看看。然後就發現了下麵這個關鍵語句,執行1127次，每次掃描3789828行導致CPU漲到100%，

SELECT *
FROM `table_info`
WHERE user_name = '　　      　              　'
        AND game_xxxx = '123abc'
        AND platform = 'xxxpay'
LIMIT 1 

於是立馬反饋給該業務的開發，複製粘貼到群里，開發說user_name是空的，開發也很快修改代碼發佈到線上，本以為就要結束了，結果還是有這樣的SQL進來，這就神奇了....然後懷疑user_name不是空的，會不會是空格，結果我複製出來到文本編輯器，因為開了符號顯示，發現user_name的值是空+空格，真想大白了，太可惡了。

 三、解決辦法

開發同事修改代碼，正則匹配過濾，業務恢復

四、個人反思

1、遇到類似問題，細心按照流程思路找問題，不要急
2、第一時間先把阿裡雲告警臨時關閉，不然一直打電話影響排錯
3、查看告警的只讀活躍會話，如果有執行特別長時間的SQL，立馬kill別影響業務。
4、如果慢查特別多，先對掃描行欄位進行排序，找出掃描行特別多的SQL再分析
5、事後總結，做好記錄，處理事故同時也得到積累和進步