MySQL效能基準測試對比:5.7 VS 8.0

qcloud發表於2019-03-07

> 本文由雲 + 社群發表

> 作者:資料庫

版權宣告:本文由騰訊雲資料庫產品團隊整理,頁面原始內容來自於 severalnines 英文官網,若轉載請註明出處。翻譯目的在於傳遞更多全球最新資料庫領域相關資訊,並不意味著騰訊雲資料庫產品團隊贊同其觀點或證實其內容的真實性。如果其他媒體、網站或其他任何形式的法律實體和個人使用,必須經過著作權人合法書面授權並自負全部法律責任。不得擅自使用騰訊雲資料庫團隊的名義進行轉載,或盜用騰訊雲資料庫團隊名義釋出資訊。

原文連結:https://severalnines.com/blog/mysql-performance-benchmarking-mysql-57-vs-mysql-80


在 Oracle MySQL 團隊的推動下,MySQL 8.0 發生了巨大的變化和修改。

物理檔案已更改。例如,.frm, .TRG,.TRN 和 .par 不再存在。新增了大量的新特性,如通用表表示式 (Common Table Expressions CTE),視窗函式(Window Functions),不可見索引( Invisible Indexes),正規表示式(regexp) -MySQL8.0 現在已經完全支援 Unicode,且具有多位元組安全特性。資料字典也發生了變化。它現在與一個事務性資料字典合併,該字典儲存有關資料庫物件的資訊。與以前的版本不同,字典資料儲存在後設資料檔案和非事務表中。

安全性得到了改進,caching_sha2_password 認證方式取代了之前的 mysql_native_password 認證方式,成為預設的身份驗證方式。它提供了更強大的靈活性,而且也加強了安全性,即它要求必須使用安全連線或通過 RSA 金鑰對實現的支援密碼交換的未加密連結。

有了 MySQL 8.0 提供的所有這些很出色的功能,以及進行的增強和改進,我們團隊很有興趣來了解下 MySQL 8.0 當前版本的效能情況。特別是考慮到我們針對 MySQL 8.0.x 設計的 ClusterControl 正在進行中(請繼續保持關注)。這篇博文不會討論 MySQL8.0 的特性,但打算將其效能與 MySQL 5.7 進行對比,看看它是如何改進的。

Server Setup and Environment 伺服器設定和環境

對於此基準測試,我打算使用基於 AWS EC2 最小配置的系統環境:

· 例項型別:t2.xlarge 例項

· 儲存:gp2(SSD 儲存,最小 100 IOPS,最大 16000 IOPS)

· 虛擬 CPU:4

· 記憶體:16GiB

· MySQL5.7 版本:MySQLCommunity Server (GPL) 5.7.24

· MySQL8.0 版本:MySQLCommunity Server - GPL 8.0.14

在這個基準測試中,我也針對一些引數項的取值進行了配置,它們是:

· innodb_max_dirty_pages_pct= 90 ## 這是 MySQL 8.0 中的預設值。

· innodb_max_dirty_pages_pct_lwm= 10 ## 這是 MySQL 8.0 中的預設值

· innodb_flush_neighbors=0

· innodb_buffer_pool_instances=8

· innodb_buffer_pool_size=8GiB

這裡對兩個版本(MySQL 5.7 和 MySQL 8.0)其餘引數項的配置是參照 ClusterControl 的 my.cnf 模板進行調優。

此外,我在這裡不使用 MySQL8.0 的新身份驗證方式,即 caching_sha2_password 認證方式。替代的是在這兩個版本中都使用 mysql_native_password,外加配置 innodb_dedicated_serve=OFF(預設值),因為 innodb_dedicated_serve 是 MySQL 8.0 的新特性。

為了簡化工作,我使用 ClusterControl 配置 MySQL 5.7 Community version 節點,然後把該節點從叢集中的剔除,使其成為一個單獨主機,並關閉叢集控制主機,使 MySQL 5.7 節點處於休眠狀態 (不監控流量)。從技術上講,MySQL 5.7 和 MySQL8.0 都是休眠節點,在節點上沒有活動連線通,因此它基本上是一個純粹的基準測試。

搜尋關注 “騰訊雲資料庫” 官方微信,立得 10 元騰訊雲無門檻代金券,體驗移動端一鍵管理資料庫,更有從初階到高階資料庫實戰教程等你來約!

Commands and Scripts Used 使用的命令和指令碼

對於此任務,sysbench 用於測試和負載模擬這兩個環境。以下測試中使用的命令和指令碼:

sb-prepare.sh #!/bin/bash host=$1#host192.168.10.110port=3306user='sysbench'password='MysqP@55w0rd'table_size=500000rate=20ps_mode='disable'sysbench/usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --threads=1--max-requests=0 --time=3600 --mysql-host=$host --mysql-user=$user--mysql-password=$password --mysql-port=$port --tables=10 --report-interval=1--skip-trx=on --table-size=$table_size --rate=$rate --db-ps-mode=$ps_modeprepare

sb-run.sh

#!/usr/bin/envbash2     host=$1port=3306user="sysbench"password="MysqP@55w0rd"table_size=100000tables=10rate=20ps_mode='disable'threads=1events=0time=5trx=100path=$PWD  counter=1   echo "thread,cpu" >${host}-cpu.csv   for i in 16 32 64 128 256 512 1024 2048; do  threads=$i  mysql -h $host -e"SHOW GLOBAL STATUS" >> $host-global-status.logtmpfile=$path/${host}-tmp${threads}touch $tmpfile/bin/bashcpu-checker.sh $tmpfile $host $threads &  /usr/share/sysbench/oltp_read_write.lua--db-driver=mysql --events=$events --threads=$threads --time=$time--mysql-host=$host --mysql-user=$user --mysql-password=$password--mysql-port=$port --report-interval=1 --skip-trx=on --tables=$tables--table-size=$table_size --rate=$rate --delete_inserts=$trx --order_ranges=$trx--range_selects=on --range-size=$trx --simple_ranges=$trx --db-ps-mode=$ps_mode--mysql-ignore-errors=all run | tee -a $host-sysbench.log   echo"${i},"`cat ${tmpfile} | sort -nr | head -1` >> ${host}-cpu.csvunlink ${tmpfile}   mysql -h $host -e"SHOW GLOBAL STATUS" >> $host-global-status.logdone   python $path/innodb-ops-parser.py $host  mysql -h $host -e "SHOW GLOBALVARIABLES" >> $host-global-vars.log

因此,指令碼只是準備 sbtestschema 並填充表和記錄。然後,它使用

/usr/share/sysbench/oltp_read_write.lua 指令碼執行讀/寫負載測試。該指令碼轉儲全域性狀態和 MySQL 變數,收集 CPU 利用率,並解析由指令碼 innodb-ops-parser.py 處理的 InnoDB 行操作。指令碼根據基準測試期間收集的轉儲日誌生成* .csv 檔案,我在這裡使用 Excel 電子表格從* .csv 檔案生成圖表。請檢查 github 中提交的程式碼。

現在,讓我們繼續處理圖表結果!

InnoDB 行操作

img

img

img

img

基本上在這裡,我只提取了 InnoDB 行操作,它執行查詢(讀取),刪除,插入和更新。當執行緒數量增加時,MySQL 8.0 明顯優於 MySQL 5.7!在這兩個版本中都沒有針對配置項進行任何個性化變更,只有我統一配置的引數項。所以這兩個版本中的配置幾乎都使用預設值。

有趣的是,MySQL 團隊關於新版本中讀寫效能的宣告,這些圖表指出了效能的顯著提高,特別是在高負載伺服器上。想一下 MySQL 5.7 和 MySQL 8.0 在 InnoDB 行操作上的區別,確實存在有很大的不同,特別是當執行緒數增加的時候。MySQL 8.0 表明,無論工作負載如何,它都能高效地執行。

事務處理

img

img

如上圖所示,MySQL 8.0 的結果趨勢顯示出其處理事務所需的時間的巨大變化。縱軸數值越低,代表效能越好,意味著處理事務的速度更快。處理的事務統計表(第二張表)還顯示出這兩個版本處理事務的數量沒有差異。這意味著,兩個版本處理的事務數量幾乎相同,但它們的完成速度不同。雖然 MySQL 5.7 在較低的負載下可以大量事務,但是實際的負載,特別是在生產中,可能會更高——尤其是在最繁忙的時期。

img

上面的圖仍然顯示的是兩個版本能夠處理的事務數量,只是將讀和寫分離開來。然而,圖中實際上是存在異常值,而我沒有將這些值包括在內,因為它們是這一小部分異常結果會扭曲圖形。

MySQL 8.0 體現出一個很大的改進,特別是對於讀取。表現在寫操作的效率上,特別是對於高工作負載的伺服器。在 8.0 版本中,影響 MySQL 讀取效能的重要新增支援是:可以按降序 (或正向索引掃描) 建立索引的能力。以前的版本只有升序或反向索引掃描,如果需要降序,MySQL 必須執行 filesort(如果需要 filesort,需要檢查 max_length_for_sort_data 的值)。當最有效的掃描順序混合某些列的升序和其他列的降序時,降序索引還使優化器可以使用多列索引。有關詳細資訊,請參見此處。

CPU 資源

img

在此基準測試中,我決定測試一些硬體資源,尤其是 CPU 利用率。

讓我先解釋一下如何在基準測試中獲取 CPU 使用率。在對資料庫進行基準測試時,sysbench 測試結果中不包括在此過程中使用的硬體資源的統計資訊。因此,我所做的是通過建立檔案的方式來建立標識,通過 SSH 連線到目標主機,然後用 Linux 命令 “top” 收集資料並在測試結束前進行解析,然後再次收集。然後分析出 mysqld 程式佔用最大的 CPU 使用量,最後刪除該標識檔案。你可以檢視我在 github 上的程式碼。

讓我們再次討論圖表結果,似乎表明 MySQL 8.0 消耗了大量的 CPU,超過 MySQL 5.7。然而,MySQL 8.0 可能必須消耗額外的 CPU 在新的變數配置上。例如,這些變數可能會影響您的 MySQL 8.0:

· innodb_log_spin_cpu_abs_lwm = 80

· innodb_log_spin_cpu_pct_hwm = 50

· innodb_log_wait_for_flush_spin_hwm = 400

· innodb_parallel_read_threads = 4

在此基準測試中,具有預設值的變數將保留其預設值。由於 MySQL 8.0 重新設計了 InnoDB 寫入 REDO 日誌的方式(這是一個改進),前三個變數可配置處理重做日誌的使用的 CPU 資源。例如,變數 innodb_log_spin_cpu_pct_hwm 具有 CPU 親和性,這意味著如果 mysqld 僅繫結到 4 個核心,它將忽略其他 CPU 核心。對於並行讀取執行緒,在 MySQL 8.0 中新增了一個新變數,您可以調整要使用的執行緒數。

然而,我沒有深入研究這個問題。可以通過利用 MySQL8.0 提供的特性來提高效能。

結論

MySQL 8.0 中有許多改進。基準測試結果顯示,與 MySQL 5.7 相比,MySQL 8.0 不僅在處理讀負載時,而且在讀寫混合的高負載下的效能都取得了令人矚目的進步。搜尋關注 “騰訊雲資料庫” 官方微信,立得 10 元騰訊雲無門檻代金券,體驗移動端一鍵管理資料庫,更有從初階到高階資料庫實戰教程等你來約!

再來看 MySQL 8.0 的新特性,看起來它不僅利用了最新的軟體技術(如 Memcached 的改進,遠端管理以獲得更好的 DevOps 工作效能等),還有硬體。例如,用 UTF8MB4 替換 latin1 作為預設字元編碼。這意味著它需要更多的磁碟空間,因為 UTF8 在非 US-ASCII 字元上需要 2 個位元組。雖然此基準測試沒有利用使用 caching_sha2_password 的新身份驗證方法,但它是否使用加密不會影響效能。一旦經過身份驗證,它就會儲存在快取中,這意味著身份驗證只進行一次。因此,如果您在客戶端只使用一個使用者,則不會出現問題,並且比以前的版本更安全。

由於 MySQL 利用最新的硬體和軟體,因此會更改其預設變數。你可以在這裡閱讀更多細節。

總的來說,MySQL 8.0 的效能已經遠超過 MySQL 5.7 了。

此文已由騰訊雲 + 社群在各渠道釋出

獲取更多新鮮技術乾貨,可以關注我們騰訊雲技術社群-雲加社群官方號及知乎機構號

更多原創文章乾貨分享,請關注公眾號
  • MySQL效能基準測試對比:5.7 VS 8.0
  • 加微信實戰群請加微信(註明:實戰群):gocnio

相關文章