在 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， 作者，PostgreSQL 專家與布道師。資料庫老司機， 。
測試
假設
測試的方法五花八門，我們當然明白，測試結果可能因各種要素而異，（例如：執行環境， MySQL 伺服器配置）。
但如果我們在同樣的平台上，比較同一個產品的多個版本，那麽可以合理假設，在不改變 MySQL 伺服器配置的前提下，影響結果的變量可以最大程度得到控制。
因此，我首先根據 MySQL 預設配置 執行效能測試，這裏的工作假設很明確，你釋出產品時使用的預設值，通常來說是最安全的配置，也經過了充分的測試。
當然，我還做了一些 配置最佳化 [2] ，並評估最佳化後的參數配置會如何影響效能。
我們進行哪些測試？
我們跑了 sysbench [3] 與 TPC-C Like [4] 兩種 Benchmark。可以在這裏找到完整的 測試方法與細節 [5] ，實際執行的命令則可以在參考連結裏找到 [6,7]
結果
我們跑完了上面一整套測試， 所有的結果都可以在這裏找到 [8] 。
但為了保持文章的簡潔和高品質，我在這裏只對 Sysbench 讀寫測試和 TPC-C 的結果進行分析與介紹。
之所以選擇這兩項測試，是因為它們直接且全面地反映了 MySQL 伺服器的表現，同時也是最常見的套用場景。其他測試更適合用來深入分析特定的問題。
在此報告中，下面進行的 sysbench 讀寫測試中，寫操作比例約為 36%，讀操作比例約為 64%，讀操作由點查詢和範圍查詢組成。而在 TPC-C 測試中，讀寫操作的比例則均為 50/50 %。
sysbench 讀寫測試
首先我們用預設配置來測試不同版本的 MySQL。
小數據集，預設配置：
小數據集，最佳化配置：
大數據集，預設配置：
大數據集，最佳化配置：
前兩幅圖表很有趣，但很顯然說明了我們不能拿
預設配置
來測效能，我們可以用它們作為基礎，找出更好的預設值。
Oracle 最近決定在 8.4 中修改許多參數的預設值，也證實了這一點（ 參見文章 [9] ）。
有鑒於此，我將重點關註透過最佳化參數配置後進行的效能評測結果。看看上面的圖表，我們不難看出：
1. 使用預設值的 MySQL 5.7 ，在兩種情況（大小數據集）下的表現都更好 2. MySQL 8.0.36 因為預設配置參數不佳，使其在第一種（小數據集）的情況表現拉垮。但只要進行一些最佳化調整，就能讓它的效能表現超過 8.4，並更接近 5.7。
TPC-C 測試
如上所述，TPC-C 測試應為寫入密集型，會使用事務，執行帶有 JOIN，GROUP，以及排序的復雜查詢。
我們使用最常用的兩種 [10] ，可重復讀（Repeatable Read），以及讀已送出（Read Committed），來執行 TPC-C 測試。
盡管我們在多次重復測試中遇到了一些問題，但都是因為一些鎖超時導致的隨機問題。
因此盡管圖中有一些空白，但都不影響大趨勢，只是壓力打滿的表現。
TPC-C，最佳化配置，RR隔離等級：
TPC-C，最佳化配置，RC隔離等級：
在本次測試中，我們可以觀察到，MySQL 5.7 的效能比其他 MySQL 版本要更好。
與 Percona 的 MySQL 和 MariaDB 比會怎樣？
為了簡潔起見，我將僅在這裏介紹最佳化參數配置的測試，原因上面說過了，預設參數沒毛用沒有。
sysbench讀寫，小數據集的測試結果：
sysbench讀寫，大數據集的測試結果：
當我們將 MySQL 的各個版本與 Percona Server MySQL 8.0.36 以及 MariaDB 11.3 進行對比時， 可以看到 MySQL 8.4 只有和 MariaDB 比時表現才更好，與 MySQL 8.0.36 比較時仍然表現落後。
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 】。 [11]
另一方面，我們不得不承認 Oracle 確實在 OCI/MySQL/Heatwave 這些產品的效能和功能上投資了很多 —— 只不過這些改進沒有體現在 MySQL 的程式碼中 ，無論是社群版還是企業版。
再次強調，我認為這一點非常可悲，但我也能理解為什麽。
當 AWS 和 Google 等雲廠商使用 MySQL 程式碼、對其進行最佳化以供自己使用、賺取數十億美元，甚至不願意將它們的程式碼回饋時，憑什麽 Oracle 就要繼續免費最佳化 MySQL 的程式碼？
我們知道這種情況已經持續了很多年了，我們也知道這對開源生態造成了極大的負面影響。
MySQL 只不過是更大場景中的一塊樂高積木而已，在這個場景中， 雲端運算公司正在吞噬其他公司的工作成果，自己用來發大財 。
我們又能做什麽？我只能希望我們能很快看到不一樣的東西：開放程式碼，投資計畫，幫助像 MySQL 這樣的社群收復失地。
與此同時，我們必須承認，許多客戶與使用者使用 MySQL 5.7 是有非常充分的理由的。在我們能解決這個問題之前， 他們可能永遠也不會決定遷移，或者，如果必須遷移的話，遷移到其他替代方案上，比如 。
然後，Sakila 將像往常一樣，因為人類的貪婪而緩慢而痛苦地死去，從某種意義上說，這種事兒並不新鮮，但很糟糕。
願 MySQL 永遠快樂
References
[1]
延長的生命周期支持:
https://www.percona.com/post-mysql-5-7-eol-support
[2]
配置最佳化:
https://github.com/Tusamarco/blogs/blob/master/sakila_where_are_you_going/config_changes.txt
[3]
sysbench:
https://github.com/akopytov/sysbench
[4]
TPC-C Like:
https://www.tpc.org/tpcc/
[5]
測試方法與細節:
https://github.com/Tusamarco/benchmarktools/blob/main/docs/plan.md
[6]
sysbench:
https://github.com/Tusamarco/benchmarktools/blob/main/software/fill_sysbench_map.sh
[7]
TPC-C:
https://github.com/Tusamarco/benchmarktools/blob/main/software/fill_tpcc_map.sh
[8]
所有的結果都可以在這裏找到:
https://github.com/Tusamarco/blogs/tree/master/sakila_where_are_you_going
[9]
參見文章:
https://lefred.be/content/mysql-8-4-lts-new-production-ready-defaults-for-innodb/
[11]
Oracle 最終會殺死 MySQL 嗎？:
https://www.percona.com/blog/can-oracle-save-mysql/
