簡述

在Oracle MySQL團隊的推動下，MySQL 8.0發(fā)生了巨大的變化和修改。

物理文件已更改。例如，*.frm，* .TRG，*.TRN和* .par 不再存在。添加了大量的新特性，如通用表表達式(Common Table Expressions CTE)，窗口函數(shù)（Window Functions），不可見索引（ Invisible Indexes），正則表達式（regexp） -MySQL8.0現(xiàn)在已經(jīng)完全支持Unicode，且具有多字節(jié)安全特性。數(shù)據(jù)字典也發(fā)生了變化。它現(xiàn)在與一個事務(wù)性數(shù)據(jù)字典合并，該字典存儲有關(guān)數(shù)據(jù)庫對象的信息。與以前的版本不同，字典數(shù)據(jù)存儲在元數(shù)據(jù)文件和非事務(wù)表中。

安全性得到了改進，caching_sha2_password認證方式取代了之前的mysql_native_password認證方式，成為默認的身份驗證方式。它提供了更強大的靈活性，而且也加強了安全性，即它要求必須使用安全連接或通過RSA密鑰對實現(xiàn)的支持密碼交換的未加密鏈接。

本篇暫不討論其新特性，而是將其性能與MySQL 5.7進行對比，看看它是如何改進的。

Server Setup and Environment服務(wù)器設(shè)置和環(huán)境

對于此基準測試，我打算使用基于AWS EC2最小配置的系統(tǒng)環(huán)境：

• 實例類型：t2.xlarge實例
• 存儲：gp2（SSD存儲，最小100 IOPS，最大16000 IOPS）
• 虛擬CPU：4
• 內(nèi)存：16GiB
• MySQL5.7版本：MySQLCommunity Server (GPL) 5.7.24
• MySQL8.0版本：MySQLCommunity Server - GPL 8.0.14

在這個基準測試中，我也針對一些參數(shù)項的取值進行了配置，它們是：

• 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）其余參數(shù)項的配置是參照ClusterControl的my.cnf模板進行調(diào)優(yōu)。

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

為了簡化工作，我使用ClusterControl配置MySQL 5.7 Community version節(jié)點，然后把該節(jié)點從集群中的剔除，使其成為一個單獨主機，并關(guān)閉集群控制主機，使MySQL 5.7節(jié)點處于休眠狀態(tài)(不監(jiān)控流量)。從技術(shù)上講，MySQL 5.7和MySQL8.0都是休眠節(jié)點，在節(jié)點上沒有活動連接通，因此它基本上是一個純粹的基準測試。

Commands and Scripts Used使用的命令和腳本

對于此任務(wù)，sysbench用于測試和負載模擬這兩個環(huán)境。以下測試中使用的命令和腳本：

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.csv 
unlink ${tmpfile} 
 mysql -h $host -e"SHOW GLOBAL STATUS" >> $host-global-status.log 
done 
  
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腳本執(zhí)行讀/寫負載測試。該腳本轉(zhuǎn)儲全局狀態(tài)和MySQL變量，收集CPU利用率，并解析由腳本innodb-ops-parser.py處理的InnoDB行操作。腳本根據(jù)基準測試期間收集的轉(zhuǎn)儲日志生成* .csv文件，我在這里使用Excel電子表格從* .csv文件生成圖表。請檢查 github中提交的代碼。

現(xiàn)在，讓我們繼續(xù)處理圖表結(jié)果！

InnoDB行操作

基本上在這里，我只提取了InnoDB行操作，它執(zhí)行查找（讀?。瑒h除，插入和更新。當線程數(shù)量增加時，MySQL 8.0明顯優(yōu)于MySQL 5.7！在這兩個版本中都沒有針對配置項進行任何個性化變更，只有我統(tǒng)一配置的參數(shù)項。所以這兩個版本中的配置幾乎都使用默認值。

有趣的是，MySQL團隊關(guān)于新版本中讀寫性能的聲明，這些圖表指出了性能的顯著提高，特別是在高負載服務(wù)器上。想一下MySQL 5.7和MySQL 8.0在InnoDB行操作上的區(qū)別，確實存在有很大的不同，特別是當線程數(shù)增加的時候。MySQL 8.0表明，無論工作負載如何，它都能高效地運行。

事務(wù)處理

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

CPU資源

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

讓我先解釋一下如何在基準測試中獲取CPU使用率。在對數(shù)據(jù)庫進行基準測試時，sysbench測試結(jié)果中不包括在此過程中使用的硬件資源的統(tǒng)計信息。因此，我所做的是通過創(chuàng)建文件的方式來創(chuàng)建標識，通過SSH連接到目標主機，然后用Linux命令“top”收集數(shù)據(jù)并在測試結(jié)束前進行解析，然后再次收集。然后分析出mysqld進程占用最大的CPU使用量，最后刪除該標識文件。你可以查看我在github上的代碼。

讓我們再次討論圖表結(jié)果，似乎表明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重新設(shè)計了InnoDB寫入REDO日志的方式（這是一個改進），前三個變量可配置處理重做日志的使用的CPU資源。例如，變量innodb_log_spin_cpu_pct_hwm具有CPU親和性，這意味著如果mysqld僅綁定到4個內(nèi)核，它將忽略其他CPU內(nèi)核。對于并行讀取線程，在MySQL 8.0中添加了一個新變量，您可以調(diào)整要使用的線程數(shù)。

結(jié)論

MySQL 8.0中有許多改進?；鶞蕼y試結(jié)果顯示，與MySQL 5.7相比，MySQL 8.0不僅在處理讀負載時，而且在讀寫混合的高負載下的性能都取得了令人矚目的進步。

再來看MySQL 8.0的新特性，看起來它不僅利用了最新的軟件技術(shù)（如Memcached的改進，遠程管理以獲得更好的DevOps工作性能等），還有硬件。例如，用UTF8MB4替換latin1作為默認字符編碼。這意味著它需要更多的磁盤空間，因為UTF8在非US-ASCII字符上需要2個字節(jié)。雖然此基準測試沒有利用使用caching_sha2_password的新身份驗證方法，但它是否使用加密不會影響性能。一旦經(jīng)過身份驗證，它就會存儲在緩存中，這意味著身份驗證只進行一次。因此，如果您在客戶端只使用一個用戶，則不會出現(xiàn)問題，并且比以前的版本更安全。