MySQL空間暴漲150G導致鎖定，發生了什麼

背景

12月1號中午突然收到大量報警，某客戶環境運算元據庫大量失敗，報錯資訊如下圖所示：

這個報錯我是第一次見，一時間有點無所適從，但是從字面意思來看是MySQL目前處於LOCK_WRITE_GROWTH狀態，拒絕執行當前的語句，一定是MySQL出問題了。

我隨即登入阿里雲控制檯檢視MySQL是否有什麼異常，果不其然執行狀態那裡提示“鎖定中（空間不足）”，我根據提示連結簡單閱讀了阿里雲關於鎖定狀態的解釋說明以及處理措施。

以下為阿里雲官方內容擷取，想了解更多細節的請前往推薦閱讀部分第一個連結。

雖說事有蹊蹺，但是為了快速恢復服務，來不及深思，立即刪除了一部分日誌型資料，釋放出來10個G左右的空間，幾分鐘以後資料庫狀態正常。

服務恢復以後我們兵分兩路，一方面聯絡客戶擴容資料庫，10G估計撐不了多長時間；另一方面我開始剝繭抽絲般的尋找程式上可能的bug，比如新上了什麼功能導致儲存過多的資料諸如此類。

透過阿里雲監控發現11月30的儲存空間佔用只有300G，到了第二天中午瞬間增長了150G左右，這很不正常，感覺一定是程式的bug，詢問一番以後發現昨晚並沒有發版，難道是個歷史bug？

怎麼揪出這個bug呢，我首先尋找阿里雲控制檯是否有表粒度的空間變化趨勢圖，找了一圈沒找到，只有整體空間的變化趨勢，似乎對排查不利，但其中一個細節引起了我的注意，請看下圖。

已總空間≠資料空間+臨時空間+日誌空間，有150G左右的空間被狗吃了？帶著問題我又找到了另一張監控，可以初步解釋那150G去哪了。

這張圖中多出來一個“mysql.other.size”，有157G左右，和上面被狗吃掉的150多G高度吻合，成功引起了我的注意，但mysql.other.size到底所謂何物？

接下來我提工單給阿里雲工程師詢問這一情況，一起看看專業人士的解答。

慢查居然還能導致資料庫空間滿，也算是彌補了我資料庫知識的又一片空白。

看下官網的一篇“RDS MySQL臨時檔案導致例項磁碟空間滿且出現“鎖定中”狀態”的相關描述（推薦閱讀第二個連結）。

事後我們重啟了資料庫，臨時表空間釋放出來150G，隨即叫停了擴容。

接下來需要清理一波慢查，避免悲劇再次發生。