MySQL升級會變慢？

不存在的。怎麼可能？

有人這樣質疑過，而且我在實際環境中也被人質疑過。其實我們想想任何一個產品如果升級導致效能變差這都不會被認可。我相信任何軟體尤其是資料庫這種核心軟體釋出之前都是經過大量的測試，不會出現這種問題的。

過去我經歷了一次質疑，十幾個MySQL從5.7升級到8，我們主要目的是解決大表加欄位停機的問題。因為MySQL8是加欄位到資料字典中去，解決了這個問題。很多開發團隊在升級過程中獲得了收益。但是事情沒那麼順利，有一次反饋說個別場景下大量單條提交變慢了。升級之前執行N萬次大約累計用時100秒，升級後同樣的操作累計用時300秒左右。場景大致為update t set xx where id=n。其中id是主鍵。這是一個普通的再普通不過的SQL。如果說這樣的都慢，我感覺那基本我們也沒法用了。我們先不談為什麼大量單條一次次提交而不是批量提交。主要是同樣的操作為什麼會慢了3倍。

我先把資料匯出一份到了一個閒置的機器上，寫了一個儲存過程。

首先在MySQL8上執行。

迴圈將近10萬次。紅色是一條條提交，綠色是批量提交效果。 每條單次提交的寫入為每次2.3毫秒左右。

接下來在5.7上執行。

迴圈將近10萬次。紅色是一條條提交，綠色是批量提交效果。 每條單次提交的寫入為每次1.4毫秒左右

結論是：

MySQL5.7單條主鍵更新平均1.4毫秒。

MySQL8.0單條主鍵更新平均2.3毫秒。

單條更新每次大約慢了30%。雖然沒有達到反饋的3倍的情況。但是這個結果很是打擊我。 我開始質疑我自己，因為我相信官方做出來的不會是這樣的，如果有問題一定是我的問題。這個觀點從我開始工作我就一直保持，有問題先找自己的。無論是作業系統、應用軟體還是資料庫，只要是通用的知名的都是經過全世界檢驗的，有問題一定是我使用不當。

這個時候我把我的想法聯絡官方，官方也說不至於這樣。讓我再看看。各路大神們也有出謀劃策的，有人建議我去跟蹤一下。開啟了跟蹤以後我對比發現。

最下面出現的times就是14和23（也就是1.4毫秒和2.3毫秒），左邊是5.7，右邊是8。我們可以發現最大區別是8裡面多了ioctl多了幾次。查閱了一下資料，可能關係不大。因為下面這個藍色顯示8還快一點。

那一定還是什麼環節上的問題。我又看了其他MySQL8上都是多了幾個IOCTL的。我想這應該是MySQL和OS互動的動作，DB本來就是要頻繁和OS互動的。

 

於是檢查作業系統：

5.7的作業系統是：CentOS 7.6.1810  CPU 16C 記憶體 32G。

8的作業系統是：CentOS 7.4.1708 CPU 16C 記憶體 32G。可以看年初作業系統版本不一樣。

本著嚴謹的態度。我決定用兩個一模一樣的再試試。

經過同事提供的克隆機器。兩臺機器僅僅資料庫不一樣。同一個宿主機的兩個虛擬機器，確保都是一樣的環境。

步驟和上面的一樣，經過10萬次的單條Update壓力測試，

MySQL5.7單條主鍵更新平均1.32毫秒。作業系統Red Hat 4.8.5-39 CPU 16C 記憶體32G

MySQL8.0單條主鍵更新平均1.40毫秒。作業系統Red Hat 4.8.5-39 CPU 16C 記憶體32G

 

結論：MySQL8和MySQL5.7在單條主鍵更新的場景下幾乎無差別。（平均慢0.08毫秒我覺得這個可以視為無差別）之前30%的慢是因為作業系統版本有差異，現在幾乎一致是因為兩個作業系統都是一致的。至於為什麼會反饋有的時候會慢3倍，我覺得主要是因為資料庫整體執行狀態。如果資料庫處於亞健康的會，產生的問題會是連鎖的。而CPU超過50%的時候資料庫就是亞健康狀態的。我之前的模擬都是兩個靜態資料庫的前提條件下，正式環境如果SQL質量過關大部分資料庫應該是近似空載狀態，那麼是可以接近於我這個壓測的狀態。（壓測為虛擬機器本地磁碟，生產環境資料庫必須是SSD）。所以歸根結蒂，還是要提高SQL質量，讓資料庫處於健康狀態才能有更好的併發。