如何三招搞掛MySQL？
本文將介紹三種搞掛MySQL的方式，逗大家一樂，同時也會揭露一些MySQL使用過程中的注意事項和實現原理，以供參考。感興趣的同學可以找一個MySQL例項進行測試。我要說的三種方式分別是：
- 產生大量undo日誌撐滿磁碟空間導致MySQL不可用；
- 定義大量使用者變數耗盡MySQL的記憶體；
- 觸發MySQL的bug。
宣告： 這裡介紹的三種方式可以搞掛目前大多數的線上MySQL例項，請謹慎測試。一切後果，本文作者及本網站概不責任哦。
一、產生大量的undo日誌
眾所周知，InnoDB是一個支援MVCC的儲存引擎，為了支援MVCC，InnoDB需要儲存undo日誌，以便對使用者提供記錄的歷史版本。如果我們開啟一個事務，反覆地更新一條記錄而不提交，會怎麼樣呢？將會產生大量的undo日誌，使得磁碟空間爆滿，導致MySQL不可用。
在innodb現有的實現中，並沒有對單個使用者或單個連線使用的undo空間進行限制。也就是說，我們只需要反覆更新一條記錄，而不提交，就會產生大量undo日誌。由於我們的事務沒有提交，undo日誌不能被回收，從而使得磁碟空間被耗盡，最終導致MySQL掛掉。
Jeremy Cole老早就提到過這個問題，不過該問題至今還存在。要進行該項測試，只需要有更新記錄的許可權即可。測試指令碼如下：
測試過程中，可以觀察磁碟空間的使用率，一直在上升：
磁碟空間滿以後，再執行SQL語句就報錯了，錯誤資訊如下：
錯誤日誌如下：
可以看到，雖然MySQL程序還存在，其實服務已經不可用了。事務在執行過程中，會產生undo日誌以及binlog日誌，佔用磁碟空間，如果我們在線上執行一個大事務，就需要留意是否有可能因為undo和binlog導致磁碟空間爆滿的情況。為了規避風險，我們還是應該儘可能地避免特別大的事務。
二、定義大量的變數
上面的例子並沒有真的讓MySQL程序掛掉，而且需要對資料庫具有寫的許可權。你可能不服，那麼，我們再來看另外一種情況，即定義大量的使用者變數。
這種方式將會導致MySQL佔用的記憶體急劇上漲，最後被作業系統kill掉。而且，不再需要有更新記錄的許可權，只需要有登入資料庫的許可權即可。
測試指令碼如下：
我們不斷地定義使用者變數，可以通過pidstat觀察MySQL佔用的記憶體：
可以看到，MySQL佔用的記憶體越來越大，最後，MySQL程序不在了。通過dmesg可以看到，是由於MySQL佔用記憶體太多，被作業系統kill掉：
上面的例子演示了一個普通使用者耗盡資源，導致MySQL被作業系統kill掉的情況。其實，這個問題是完全可以避免的。MySQL支援在建立使用者的時候，限制使用者使用的資源。
可以限制的資源包括：
每小時的查詢次數
每小時的更新次數
每小時的連線次數
同時建立的連線數
使用方式如下所示：
雖然MySQL支援限制使用者使用的資源，但是，在實際使用過程中，很少有人會去限制使用者使用的資源，甚至很多使用者根本不知道MySQL提供了這樣的功能，這給”不法分子”有了可乘之機。
三、觸發MySQL的bug
可以說，寫MySQL的都是一群科學家，並且，MySQL使用如此廣泛，遇到MySQL的bug應該不容易。不過，只要是程式就有可能存在bug，所以，遇到MySQL的bug也不是不可能的情況。如果看MySQL的release note，每次的新版本都會修復無數的bug。尤其以新功能的bug居多。
這一節，我們來測試一下MySQL的bug。即在使用grant授權時，如果使用了一個很長的資料庫名，將導致MySQL掛掉。之所以選擇這個bug，是因為該bug復現起來特別容易了，只需要執行一條SQL語句即可。
如下所示：
很明顯，該問題是由於緩衝區溢位導致，這也是我們程式設計中容易犯的一個錯誤。這個bug在MySQL 5.7中已經修復，我在5.6.19中進行測試，MySQL立馬掛掉，可以說是搞掛MySQL的最快方式。
四、總結
在本文中，我演示了三種搞掛MySQL的方式，這三種方式的思路不同，涉及到的知識點也不一樣。將這三種方式都嘗試一遍，可以搞掛正在使用的無數MySQL例項。那麼，是不是說MySQL特別脆弱，非常容易被搞掛呢？答案是否定的。MySQL在各網際網路公司廣泛使用，已經經受住了無數的考驗。
本文之所以顯得MySQL容易被搞掛，主要還是因為大部分人的使用姿勢不當，以及對MySQL的瞭解不足所導致的。要避免MySQL掛掉，這裡有幾點建議：
特別大的事務會佔用特別多的資源，甚至出現佔滿磁碟空間的情況，要避免特別大的事務；
限制使用者使用的資源，避免不良使用者惡意破壞；
緊隨社群的腳步，關注社群報告和修復的bug，必要時升級資料庫版本，以免遇到已知bug；
新功能一般bug較多，不要上得太快，避免踩到未知bug。