正文
背景
最早
環境
測試
雙1模式下
0 2模式下
摘要
背景
測試mysql5。7和mysql8。0分別在讀寫，選定，只寫模式下不同併發時的效能（tps，qps）
最早
測試使用版本為mysql5。7。22和mysql8。0。15
sysbench測試前先重啟mysql服務，並清除os的快取（避免多次測試時命中快取）
每次進行測試都是新生成測試資料後再進行mysql5。7和mysql8。0的測試
每次測試時保證mysql5。7和mysql8。0的配置引數一致
環境
機器
cat / etc / redhat-release | xargs echo‘版本’&& dmidecode -s系統產品名稱| xargs echo‘是否虛擬化’&& cat / proc / cpuinfo | grep“ processor” | wc -l | xargs echo‘cpu核數’版本CentOS Linux版本7。5。1804（核心）是否虛擬化KVM cpu核數4
myql5.7.22
mysql8.0.15
系統平臺
測試
在不同的持久化策略下（binlog，重做日誌持久化）mysql5.7和mysql8.0在讀寫模式，引用模式，只寫模式（oltp_read_write，oltp_read_only，oltp_write_only）下的效能表現
sysbench測試時間為60s，測試的表數量為20
測試分別在雙1模式（安全性）和0 2模式（高階）下進行
雙1模式下
mysql5.7和mysql8.0在讀寫模式下的表現
雙1配置，讀寫模式下，mysql5。7。22和mysql8。0。15 tps，qps效能差不多，mysql8。0。15在120執行緒併發時，效能出現了下降幅度
mysql5.7和mysql8.0在預期模式下的表現
雙1配置，預期模式下，mysql5。7。22的tps，qps比mysql8。0。15好1/3左右；併發執行緒數增加後，tps，qps並沒有增加，反而出現了下降的趨勢
mysql5.7和mysql8.0在只寫模式下的表現
雙1配置，只寫模式下，轉換併發數的上升，mysql5。7。22的效能比mysql8。0。15好1/4左右
0 2模式下
mysql5.7和mysql8.0在讀寫模式下的表現
0 2配置，讀寫模式下，併發數低時，mysql5。7。22效能好於mysql8。0。15； 併發數比較高時，mysql8。0。15效能好於mysql5。7。22；在80執行緒的併發以上時，效能開始下降
mysql5.7和mysql8.0在預期模式下的表現
0 2配置，預期模式下，mysql5。7。22效能比mysql8。0。15好1/3左右；轉換併發數的上升，效能也沒有上升，反而有下降的趨勢
mysql5.7和mysql8.0在只寫模式下的表現
0 2配置，只寫模式下，mysql5。7。22的tps頂點比較大；mysql5。7。22的qps比mysql8。0。15好1/3左右
摘要
整體來看，mysql5.7.22在讀寫模式，擴充套件模式，只寫模式下的表現是mysql8.0.15的
隨著並行數的增加，效能表現不會也跟著增加，將會出現下降
本次測試結果是在配置很低的情況下進行的，不代表絕對
注意
sysbench需要設定——db-ps-mode = disable禁用預編譯語句，不然併發測試執行緒多時會報下面的錯誤。致命：mysql_stmt_prepare（）失敗致命：MySQL錯誤：1461“不能建立超過max_prepared_stmt_count語句（當前值：16382）“致命：mysql_stmt_prepare（）失敗致命：MySQL錯誤：1461”不能建立超過max_prepared_stmt_count語句（當前值：16382）“致命：thread_init‘函式失敗：/ usr / local / share / sysbench / oltp_common。lua：288：SQL API錯誤致命：mysql_stmt_prepare（）失敗
使用指令碼
版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝！
感謝閱讀