MySQL效能基準測試對比:5.7 VS 8.0
> 本文由雲 + 社群發表
> 作者:資料庫
版權宣告:本文由騰訊雲資料庫產品團隊整理,頁面原始內容來自於 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 行操作
基本上在這裡,我只提取了 InnoDB 行操作,它執行查詢(讀取),刪除,插入和更新。當執行緒數量增加時,MySQL 8.0 明顯優於 MySQL 5.7!在這兩個版本中都沒有針對配置項進行任何個性化變更,只有我統一配置的引數項。所以這兩個版本中的配置幾乎都使用預設值。
有趣的是,MySQL 團隊關於新版本中讀寫效能的宣告,這些圖表指出了效能的顯著提高,特別是在高負載伺服器上。想一下 MySQL 5.7 和 MySQL 8.0 在 InnoDB 行操作上的區別,確實存在有很大的不同,特別是當執行緒數增加的時候。MySQL 8.0 表明,無論工作負載如何,它都能高效地執行。
事務處理
如上圖所示,MySQL 8.0 的結果趨勢顯示出其處理事務所需的時間的巨大變化。縱軸數值越低,代表效能越好,意味著處理事務的速度更快。處理的事務統計表(第二張表)還顯示出這兩個版本處理事務的數量沒有差異。這意味著,兩個版本處理的事務數量幾乎相同,但它們的完成速度不同。雖然 MySQL 5.7 在較低的負載下可以大量事務,但是實際的負載,特別是在生產中,可能會更高——尤其是在最繁忙的時期。
上面的圖仍然顯示的是兩個版本能夠處理的事務數量,只是將讀和寫分離開來。然而,圖中實際上是存在異常值,而我沒有將這些值包括在內,因為它們是這一小部分異常結果會扭曲圖形。
MySQL 8.0 體現出一個很大的改進,特別是對於讀取。表現在寫操作的效率上,特別是對於高工作負載的伺服器。在 8.0 版本中,影響 MySQL 讀取效能的重要新增支援是:可以按降序 (或正向索引掃描) 建立索引的能力。以前的版本只有升序或反向索引掃描,如果需要降序,MySQL 必須執行 filesort(如果需要 filesort,需要檢查 max_length_for_sort_data 的值)。當最有效的掃描順序混合某些列的升序和其他列的降序時,降序索引還使優化器可以使用多列索引。有關詳細資訊,請參見此處。
CPU 資源
在此基準測試中,我決定測試一些硬體資源,尤其是 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 了。
此文已由騰訊雲 + 社群在各渠道釋出
獲取更多新鮮技術乾貨,可以關注我們騰訊雲技術社群-雲加社群官方號及知乎機構號
- 加微信實戰群請加微信(註明:實戰群):gocnio
相關文章
- linux tinydrm vs fbtft 效能對比測試Linux
- MYSQL 效能測試方法 - 基準測試(benchmarking)MySql
- php8.0 及php7.2效能基準簡單測試PHP
- PostgreSQL TPROC-C基準測試:PostgreSQL 12與PostgreSQL 13效能對比SQL
- MySQL5.7/8.0效能分析shell指令碼MySql指令碼
- mysql 5.7 vs 8.0預設值變化(筆記)MySql筆記
- postgresql:pgbench基準效能測試SQL
- Tomcat vs Jetty vs Undertow效能對比TomcatJetty
- 使用Sysbench對滴滴雲MySQL進行基準測試MySql
- MySQL學習 - 基準測試MySql
- Linux系統下祼機安裝mysql8.0和docker mysql 8.0 效能差異對比~LinuxMySqlDocker
- Nginx 和 Gunicorn 效能對比測試Nginx
- MySQL 5.7 升級到 8.0MySql
- MySQL 5.7和8.0 MHA架構下sysbench壓測MySql架構
- 敏捷測試VS傳統測試對比,6招玩轉敏捷測試!敏捷測試
- Web Socket 效能對比——Spring Boot vs Tomcat vs NettyWebSpring BootTomcatNetty
- 公有云RDS-MySQL基準測試MySql
- Java基準效能測試--JMH使用介紹Java
- hadoop基準測試_Hadoop TeraSort基準測試Hadoop
- TIDB和MySQL效能對比TiDBMySql
- c# sqlsugar,hisql,freesql orm框架全方位效能測試對比 sqlserver 效能測試C#SqlSugarORM框架Server
- Web Socket 效能對比——Spring Boot vs TomWebSpring Boot
- windows同時安裝 5.7 8.0 mysqlWindowsMySql
- 【總結】簡述 MySQL 基準測試工具MySql
- [總結] 簡述 MySQL 基準測試工具MySql
- 利用sysbench進行MySQL OLTP基準測試MySql
- Python 3.11效能基準測試看起來很棒 - PhoronixPython
- 基準測試
- locust 與 jmeter 效能測試對比會更優?JMeter
- MySQL5.7&8.0許可權-角色管理MySql
- 基於TPC-C基準的Python ORM的效能測試PythonORM
- 精準測試:基於 asm+javaparser 呼叫鏈差異化對比實踐ASMJava
- TDengine 和 InfluxDB 查詢效能對比測試報告UX測試報告
- sqlsugar freesql hisql 三個ORM框架效能測試對比SqlSugarORM框架
- TGI 基準測試
- benchmark 基準測試
- MinkowskiEngine基準測試
- Altair SimSolid模擬速度與準確性測試對比AISolid