MySQL性能基准测试对比:MySQL 5.7与MySQL 8.0
版權(quán)聲明:本文由騰訊云數(shù)據(jù)庫產(chǎn)品團(tuán)隊整理,頁面原始內(nèi)容來自于db weekly英文官網(wǎng),若轉(zhuǎn)載請注明出處。翻譯目的在于傳遞更多全球最新數(shù)據(jù)庫領(lǐng)域相關(guān)信息,并不意味著騰訊云數(shù)據(jù)庫產(chǎn)品團(tuán)隊贊同其觀點(diǎn)或證實(shí)其內(nèi)容的真實(shí)性。如果其他媒體、網(wǎng)站或其他任何形式的法律實(shí)體和個人使用,必須經(jīng)過著作權(quán)人合法書面授權(quán)并自負(fù)全部法律責(zé)任。不得擅自使用騰訊云數(shù)據(jù)庫團(tuán)隊的名義進(jìn)行轉(zhuǎn)載,或盜用騰訊云數(shù)據(jù)庫團(tuán)隊名義發(fā)布信息。
在Oracle MySQL團(tuán)隊的推動下,MySQL 8.0發(fā)生了巨大的變化和修改。
物理文件已更改。例如,*.frm,* .TRG,*.TRN和* .par?不再存在。添加了大量的新特性,如通用表表達(dá)式(Common Table Expressions CTE),窗口函數(shù)(Window Functions),不可見索引(?Invisible Indexes),正則表達(dá)式(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ù)表中。
安全性得到了改進(jìn),caching_sha2_password認(rèn)證方式取代了之前的mysql_native_password認(rèn)證方式,成為默認(rèn)的身份驗(yàn)證方式。它提供了更強(qiáng)大的靈活性,而且也加強(qiáng)了安全性,即它要求必須使用安全連接或通過RSA密鑰對實(shí)現(xiàn)的支持密碼交換的未加密鏈接。
有了MySQL 8.0提供的所有這些很出色的功能,以及進(jìn)行的增強(qiáng)和改進(jìn),我們團(tuán)隊很有興趣來了解下MySQL 8.0當(dāng)前版本的性能情況。特別是考慮到我們針對MySQL 8.0.x設(shè)計的ClusterControl正在進(jìn)行中(請繼續(xù)保持關(guān)注)。這篇博文不會討論MySQL8.0的特性,但打算將其性能與MySQL 5.7進(jìn)行對比,看看它是如何改進(jìn)的。
對于此基準(zhǔn)測試,我打算使用基于AWS EC2最小配置的系統(tǒng)環(huán)境:
·??????實(shí)例類型:t2.xlarge實(shí)例
·??????存儲: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
在這個基準(zhǔn)測試中,我也針對一些參數(shù)項(xiàng)的取值進(jìn)行了配置,它們是:
·??????innodb_max_dirty_pages_pct= 90 ##這是MySQL 8.0中的默認(rèn)值。
·??????innodb_max_dirty_pages_pct_lwm= 10 ##這是MySQL 8.0中的默認(rèn)值
·??????innodb_flush_neighbors=0
·??????innodb_buffer_pool_instances=8
·??????innodb_buffer_pool_size=8GiB
這里對兩個版本(MySQL 5.7和MySQL 8.0)其余參數(shù)項(xiàng)的配置是參照ClusterControl的my.cnf模板進(jìn)行調(diào)優(yōu)。
此外,我在這里不使用MySQL8.0的新身份驗(yàn)證方式,即caching_sha2_password認(rèn)證方式。替代的是在這兩個版本中都使用mysql_native_password,外加配置innodb_dedicated_serve=OFF(默認(rèn)值),因?yàn)閕nnodb_dedicated_serve是MySQL 8.0的新特性。
為了簡化工作,我使用ClusterControl配置MySQL 5.7 Community version節(jié)點(diǎn),然后把該節(jié)點(diǎn)從集群中的剔除,使其成為一個單獨(dú)主機(jī),并關(guān)閉集群控制主機(jī),使MySQL 5.7節(jié)點(diǎn)處于休眠狀態(tài)(不監(jiān)控流量)。從技術(shù)上講,MySQL 5.7和MySQL8.0都是休眠節(jié)點(diǎn),在節(jié)點(diǎn)上沒有活動連接通,因此它基本上是一個純粹的基準(zhǔn)測試。
對于此任務(wù),sysbench用于測試和負(fù)載模擬這兩個環(huán)境。以下測試中使用的命令和腳本:
sb-run.sh
因此,腳本只是準(zhǔn)備sbtestschema并填充表和記錄。然后,它使用
/usr/share/sysbench/oltp_read_write.lua腳本執(zhí)行讀/寫負(fù)載測試。該腳本轉(zhuǎn)儲全局狀態(tài)和MySQL變量,收集CPU利用率,并解析由腳本innodb-ops-parser.py處理的InnoDB行操作。腳本根據(jù)基準(zhǔn)測試期間收集的轉(zhuǎn)儲日志生成* .csv文件,我在這里使用Excel電子表格從* .csv文件生成圖表。請檢查?github中提交的代碼。
現(xiàn)在,讓我們繼續(xù)處理圖表結(jié)果!
基本上在這里,我只提取了InnoDB行操作,它執(zhí)行查找(讀取),刪除,插入和更新。當(dāng)線程數(shù)量增加時,MySQL 8.0明顯優(yōu)于MySQL 5.7!在這兩個版本中都沒有針對配置項(xiàng)進(jìn)行任何個性化變更,只有我統(tǒng)一配置的參數(shù)項(xiàng)。所以這兩個版本中的配置幾乎都使用默認(rèn)值。
有趣的是,MySQL團(tuán)隊關(guān)于新版本中讀寫性能的聲明,這些圖表指出了性能的顯著提高,特別是在高負(fù)載服務(wù)器上。想一下MySQL 5.7和MySQL 8.0在InnoDB行操作上的區(qū)別,確實(shí)存在有很大的不同,特別是當(dāng)線程數(shù)增加的時候。MySQL 8.0表明,無論工作負(fù)載如何,它都能高效地運(yùn)行。
如上圖所示,MySQL 8.0的結(jié)果趨勢顯示出其處理事務(wù)所需的時間的巨大變化。縱軸數(shù)值越低,代表性能越好,意味著處理事務(wù)的速度更快。處理的事務(wù)統(tǒng)計表(第二張表)還顯示出這兩個版本處理事務(wù)的數(shù)量沒有差異。這意味著,兩個版本處理的事務(wù)數(shù)量幾乎相同,但它們的完成速度不同。雖然MySQL 5.7在較低的負(fù)載下可以大量事務(wù),但是實(shí)際的負(fù)載,特別是在生產(chǎn)中,可能會更高——尤其是在最繁忙的時期。
上面的圖仍然顯示的是兩個版本能夠處理的事務(wù)數(shù)量,只是將讀和寫分離開來。然而,圖中實(shí)際上是存在異常值,而我沒有將這些值包括在內(nèi),因?yàn)樗鼈兪沁@一小部分異常結(jié)果會扭曲圖形。
MySQL 8.0體現(xiàn)出一個很大的改進(jìn),特別是對于讀取。表現(xiàn)在寫操作的效率上,特別是對于高工作負(fù)載的服務(wù)器。在8.0版本中,影響MySQL讀取性能的重要新增支持是:可以按降序(或正向索引掃描)創(chuàng)建索引的能力。以前的版本只有升序或反向索引掃描,如果需要降序,MySQL必須執(zhí)行filesort(如果需要filesort,需要檢查max_length_for_sort_data的值)。當(dāng)最有效的掃描順序混合某些列的升序和其他列的降序時,降序索引還使優(yōu)化器可以使用多列索引。有關(guān)詳細(xì)信息,請參見此處。
在此基準(zhǔn)測試中,我決定測試一些硬件資源,尤其是CPU利用率。
讓我先解釋一下如何在基準(zhǔn)測試中獲取CPU使用率。在對數(shù)據(jù)庫進(jìn)行基準(zhǔn)測試時,sysbench測試結(jié)果中不包括在此過程中使用的硬件資源的統(tǒng)計信息。因此,我所做的是通過創(chuàng)建文件的方式來創(chuàng)建標(biāo)識,通過SSH連接到目標(biāo)主機(jī),然后用Linux命令“top”收集數(shù)據(jù)并在測試結(jié)束前進(jìn)行解析,然后再次收集。然后分析出mysqld進(jìn)程占用最大的CPU使用量,最后刪除該標(biāo)識文件。你可以查看我在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
在此基準(zhǔn)測試中,具有默認(rèn)值的變量將保留其默認(rèn)值。由于MySQL 8.0重新設(shè)計了InnoDB寫入REDO日志的方式(這是一個改進(jìn)),前三個變量可配置處理重做日志的使用的CPU資源。例如,變量innodb_log_spin_cpu_pct_hwm具有CPU親和性,這意味著如果mysqld僅綁定到4個內(nèi)核,它將忽略其他CPU內(nèi)核。對于并行讀取線程,在MySQL 8.0中添加了一個新變量,您可以調(diào)整要使用的線程數(shù)。
然而,我沒有深入研究這個問題。可以通過利用MySQL8.0提供的特性來提高性能。
MySQL 8.0中有許多改進(jìn)。基準(zhǔn)測試結(jié)果顯示,與MySQL 5.7相比,MySQL 8.0不僅在處理讀負(fù)載時,而且在讀寫混合的高負(fù)載下的性能都取得了令人矚目的進(jìn)步。
再來看MySQL 8.0的新特性,看起來它不僅利用了最新的軟件技術(shù)(如Memcached的改進(jìn),遠(yuǎn)程管理以獲得更好的DevOps工作性能等),還有硬件。例如,用UTF8MB4替換latin1作為默認(rèn)字符編碼。這意味著它需要更多的磁盤空間,因?yàn)閁TF8在非US-ASCII字符上需要2個字節(jié)。雖然此基準(zhǔn)測試沒有利用使用caching_sha2_password的新身份驗(yàn)證方法,但它是否使用加密不會影響性能。一旦經(jīng)過身份驗(yàn)證,它就會存儲在緩存中,這意味著身份驗(yàn)證只進(jìn)行一次。因此,如果您在客戶端只使用一個用戶,則不會出現(xiàn)問題,并且比以前的版本更安全。
由于MySQL利用最新的硬件和軟件,因此會更改其默認(rèn)變量。你可以在這里細(xì)節(jié)。
總的來說,MySQL 8.0的性能已經(jīng)遠(yuǎn)超過MySQL 5.7了。
本文轉(zhuǎn)自公眾號【騰訊數(shù)據(jù)庫TencentDB】,掃描以下二維碼可以關(guān)注。
總結(jié)
以上是生活随笔為你收集整理的MySQL性能基准测试对比:MySQL 5.7与MySQL 8.0的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 最佳实践:HTAP数据库TBase助力某
- 下一篇: 腾讯云数据库闪耀曼哈顿,CynosDB回