低併發場景下Mysql性能測試--新版Mysql QPS 降幅劇增

時間 2021-08-14

標籤 mysql sql 數據庫服務器併發 ide 性能測試 spa 線程欄目 MySQL 简体版

原文原文鏈接

女主宣言mysql

前幾天看了Mark Callaghan的《Sysbench for MySQL 5.0, 5.1, 5.5, 5.6, 5.7 and 8》（http://sep9.cn/cvxjwz），一篇關於mysql各版本在低併發場景下性能降低的壓測報告，經過各種測試結果對比得出：最大的QPS降幅出如今5.6和5.7這兩個版本之間，而且這個降幅一般會超過5.0和5.6版本之間的降幅（此結論爲原文做者的觀點）。這個結論是怎麼來的呢？在此將翻譯後的文章分享給你們，但願對你們有所幫助！sql

注：本文裏的網址連接須要***後訪問。數據庫

PS：豐富的一線技術、多元化的表現形式，盡在「HULK一線技術雜談」，點關注哦！服務器

背景簡介併發

在分享了將全內存sysbench壓測應用於MySQL 5.6, 5.7 和 8的結果以後，我又想探究一下老版本的狀況。因而又測試獲得了針對於MySQL 5.0, 5.1 及5.5 的結果，做爲MySQL 5.6, 5.7 和 8結果的補充，這是基於低併發性能降低系列的又一成果。ide

1.MySQL 4.1 和 5.5版本在性能上表現的並非很是好，所以跳過了這兩個版本。性能

2.最大的QPS降幅出如今5.6和5.7這兩個版本之間，而且這個降幅一般會超過5.0和5.6版本之間的降幅，到底發生了什麼呢？具體緣由能夠參考Bug 86215（http://sep9.cn/ci0hix）測試

配置spa

在壓測中，使用了upstream 5.0.96, 5.1.72, 5.5.51, 5.6.35, 5.7.17 和 8.0.1測試了MySQL。在8.0.1中，使用了latin1 charset和latin1_swedish_ci collation。本文主要分享的是基於i5 NUC的結果。線程

我曾在相同的服務器上編譯並運行了MySQL 4.1.22，可是並無分享其結果，主要緣由是該結果表現的不是很好，這一點也驗證了印象中的「4.1並非一個很好的版本」的觀點。4.0是一個很棒的版本，可是還沒讓它在擁有gcc 4.7或4.8的Ubuntu 16.04上運行，由於在啓動不久後就會出現segfaults(段錯誤)。

在使用的sysbench中，包含了測試運行，而且對MySQL 5.6, 5.7 和 8 在（http://sep9.cn/pzrah5）裏描述了每個引擎中使用的對應的my.cnf文件。這次分享my.cnf文件是針對於i3 NUC，對於i5 NUC，InnoDB buffer pool 和 IO capacity選項能夠經過使用這些變量來增長，如下這些是針對5.0、5.一、5.5的my.cnf文件。對於mysqld和sysbench clients，使用了相同的服務器，binlog 是enabled的，但sync-on-commit是disabled的。測試表爲4張，每張表有1M數據，測試場景爲一、二、4個線程壓測，該數據庫適合存放在InnoDB buffer pool中。

結果

全部測試的QPS數據在（http://sep9.cn/f0kp1g )裏記錄，一些測試的圖表在下面展現。

下表列出了每一個測試中各個版本相對於MySQL 5.0的QPS。當值爲0.53時（看MySQL 8列的update-index），那麼MySQL 8的QPS是5.0的53%，至關於MySQL 5.0比MySQL 8要快2倍。如前面所述，5.6到5.7性能降低是很是大的，但幸運的是，5.7至8並無重蹈覆轍。

這給了咱們但願，開始，我曾認爲隨着功能的增長和代碼路徑的增加，會致使每一個主要版本的性能的持續降低，可是如今看來，大部分問題都出如今了5.7中，或許能夠解決這個問題。