MySQL版本越高、效能越差？你怎麽想？

在 Percona，我們時刻關註使用者的需求，並盡力滿足他們。我們特別監控了 MySQL 版本的分布和使用情況，發現了一個引人註目的趨勢： 從版本 5.7 遷移到 8.x 的步伐明顯緩慢。 更準確地說， 許多使用者仍需堅持使用 5.7 版本。

基於這一發現，我們采取了幾項措施。首先，我們與一些仍在使用 MySQL 5.7 的使用者聊了聊，探究他們不想遷移到 8.x 的原因。為此，我們制定了 EOL 計劃，為 5.7 版本提供 延長的生命周期支持[1] ，確保需要依賴舊版本、二進制檔及程式碼修復的使用者能夠得到專業支持。

同時，我們對不同版本的 MySQL 進行了廣泛測試，以評估是否有任何 效能下降 。雖然測試尚未結束，但我們已經收集了足夠的數據，開始繪制相關圖表。本文是對我們測試結果的初步解讀。

劇透警告： 對於像我這樣熱愛 Sakila 的人來說，這些發現可能並不令人高興。

譯者註： Sakila 是 MySQL 的吉祥物 海豚

作者： Percona Blog，Marco Tusa。Percona 是 MySQL 生態的重要貢獻者，開發了知名的PT系列工具，MySQL備份工具，監控工具與發行版。

譯者： 馮若航，網名 Vonng，Pigsty 作者，PostgreSQL 專家與布道師。資料庫老司機，雲端運算土石流。

一、測試

1、假設

測試的方法五花八門，我們當然明白，測試結果可能因各種要素而異，（例如：執行環境， MySQL 伺服器配置）。但如果我們在同樣的平台上，比較同一個產品的多個版本，那麽可以合理假設，在不改變 MySQL 伺服器配置的前提下，影響結果的變量可以最大程度得到控制。

因此，我首先根據 MySQL 預設配置 執行效能測試，這裏的工作假設很明確，你釋出產品時使用的預設值，通常來說是最安全的配置，也經過了充分的測試。當然，我還做了一些 配置最佳化[2] ，並評估最佳化後的參數配置會如何影響效能。

2、我們進行哪些測試？

我們跑了 sysbench[3] 與 TPC-C Like[4] 兩種 Benchmark。可以在這裏找到完整的測試方法與細節[5]，實際執行的命令則可以在參考連結裏找到 [6,7]

二、結果

我們跑完了上面一整套測試，所有的結果都可以在這裏找到[8]。

但為了保持文章的簡潔和高品質，我在這裏只對 Sysbench 讀寫測試和 TPC-C 的結果進行分析與介紹。之所以選擇這兩項測試，是因為它們直接且全面地反映了 MySQL 伺服器的表現，同時也是最常見的套用場景。其他測試更適合用來深入分析特定的問題。

在此報告中，下面進行的 sysbench 讀寫測試中，寫操作比例約為 36%，讀操作比例約為 64%，讀操作由點查詢和範圍查詢組成。而在 TPC-C 測試中，讀寫操作的比例則均為 50/50 %。

1、sysbench 讀寫測試

首先我們用預設配置來測試不同版本的 MySQL。

小數據集，預設配置：

小數據集，最佳化配置：

大數據集，預設配置：

大數據集，最佳化配置：

前兩幅圖表很有趣，但很顯然說明了我們不能拿 預設配置 來測效能，我們可以用它們作為基礎，找出更好的預設值。Oracle 最近決定在 8.4 中修改許多參數的預設值，也證實了這一點（參見文章[9]）。

有鑒於此，我將重點關註透過最佳化參數配置後進行的效能評測結果。看看上面的圖表，我們不難看出：

使用預設值的 MySQL 5.7 ，在兩種情況（大小數據集）下的表現都更好。2.MySQL 8.0.36 因為預設配置參數不佳，使其在第一種（小數據集）的情況表現拉垮。但只要進行一些最佳化調整，就能讓它的效能表現超過 8.4，並更接近 5.7。

2、TPC-C 測試

如上所述，TPC-C 測試應為寫入密集型，會使用事務，執行帶有 JOIN，GROUP，以及排序的復雜查詢。

我們使用最常用的兩種 隔離等級[10] ，可重復讀（Repeatable Read），以及讀已送出（Read Committed），來執行 TPC-C 測試。

盡管我們在多次重復測試中遇到了一些問題，但都是因為一些鎖超時導致的隨機問題。因此盡管圖中有一些空白，但都不影響大趨勢，只是壓力打滿的表現。

TPC-C，最佳化配置，RR隔離等級：

TPC-C，最佳化配置，RC隔離等級：

在本次測試中，我們可以觀察到，MySQL 5.7 的效能比其他 MySQL 版本要更好。

3、與 Percona 的 MySQL 和 MariaDB 比會怎樣？

為了簡潔起見，我將僅在這裏介紹最佳化參數配置的測試，原因上面說過了，預設參數沒毛用沒有。

sysbench讀寫，小數據集的測試結果：

sysbench讀寫，大數據集的測試結果：

當我們將 MySQL 的各個版本與 Percona Server MySQL 8.0.36 以及 MariaDB 11.3 進行對比時， 可以看到 MySQL 8.4 只有和 MariaDB 比時表現才更好，與 MySQL 8.0.36 比較時仍然表現落後。

4、TPC-C

TPC-C，RR隔離等級的測試結果：

TPC-C，RC隔離等級的測試結果：

正如預期的那樣，MySQL 8.4 在這裏的表現也不佳，只有 MariaDB 表現更差墊底。順便一提，Percona Server for MySQL 8.0.36 是唯一能處理好並行爭用增加的 MySQL。

三、這些測試說明了什麽？

坦白說，我們在這裏測出來的結果，也是我們大多數使用者的親身經歷 —— MySQL 的效能隨著版本增加而下降。

當然，MySQL 8.x 有一些有趣的新增功能， 但如果你將效能視為首要且最重要的主題，那麽 MySQL 8.x 並沒有更好。

話雖如此，我們必須承認 —— 大多數仍在使用 MySQL 5.7 的人可能是對的（有成千上萬的人）。 為什麽要冒著極大的風險進行遷移，結果發現卻損失了相當大一部份的效能呢？

關於這一點，可以用 TPC-C 測試結果來說明，我們可以把數據轉換為每秒事務數吞吐量，然後比較效能損失了多少：

TPC-C，RR隔離等級，MySQL 8.4 的效能折損：

TPC-C，RC隔離等級，MySQL 8.4 的效能折損：

我們可以看到，在兩項測試中，MySQL 8.x 的效能劣化都非常明顯，而其帶來的好處（如果有的話）卻並不顯著。

使用數據的絕對值：

TPC-C，RR隔離等級，MySQL 8.4 的效能折損：

TPC-C，RC隔離等級，MySQL 8.4 的效能折損：

在這種情況下，我們需要問一下自己：我的業務可以應對這樣的效能劣化嗎？

四、一些思考

當年 MySQL 被賣給 SUN Microsystems 時，我就在 MySQL AB 工作，我對這筆收購非常不高興。當 Oracle 接管 SUN 時，我非常擔心 Oracle 可能會決定幹掉 MySQL，我決定加入另一家公司繼續搞這個。

此後幾年裏，我改了主意，開始支持和推廣 Oracle 在 MySQL 上的工作。從各種方面來看，我現在依然還在支持和推廣它。

他們在規範開發流程方面做得很好，程式碼清理工作也卓有成效。但是， 其他程式碼上卻沒啥進展，我們看到的效能下降，就是這種缺乏進展的代價； 請參閱 Peter 的文章【Oracle 正在殺死 MySQL 】。[10]

另一方面，我們不得不承認 Oracle 確實在 OCI/MySQL/Heatwave 這些產品的效能和功能上投資了很多 —— 只不過這些改進沒有體現在 MySQL 的程式碼中， 無論是社群版還是企業版。

再次強調，我認為這一點非常可悲，但我也能理解為什麽。

當 AWS 和 Google 等雲廠商使用 MySQL 程式碼、對其進行最佳化以供自己使用、賺取數十億美元，甚至不願意將它們的程式碼回饋時，憑什麽 Oracle 就要繼續免費最佳化 MySQL 的程式碼？

我們知道這種情況已經持續了很多年了，我們也知道這對開源生態造成了極大的負面影響。MySQL 只不過是更大場景中的一塊樂高積木而已，在這個場景中， 雲端運算公司正在吞噬其他公司的工作成果，自己用來發大財。

我們又能做什麽？我只能希望我們能很快看到不一樣的東西：開放程式碼，投資計畫，幫助像 MySQL 這樣的社群收復失地。

與此同時，我們必須承認，許多客戶與使用者使用 MySQL 5.7 是有非常充分的理由的。在我們能解決這個問題之前， 他們可能永遠也不會決定遷移，或者，如果必須遷移的話，遷移到其他替代方案上，比如 PostgreSQL。

然後，Sakila 將像往常一樣，因為人類的貪婪而緩慢而痛苦地死去，從某種意義上說，這種事兒並不新鮮，但很糟糕。

願 MySQL 永遠快樂

> > > >

參考資料

作者丨馮若航

來源丨公眾號：非法加馮 （ID： addvon）

dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]