共計 2991 個字符，預計需要花費 8 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章主要介紹 MySQL 如何測試，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

前言：

基準測試 benchmark：基本技能，是針對系統設計的一種壓力測試，是唯一方便有效、可學習系統在給定的工作負載下回發生什么 的方法，他可以觀察系統在不同壓力下的行為，評估系統的容量，掌握哪些是重要的變化，或觀察系統如何處理不同的數據，可在系統實際負載外創建虛擬場景進行測試（掌握系統行為）

正文：

如前言，基準測試很、重、要！可以完成的工作：總的來說：測試硬件、預估硬件、驗證系統、測壓力、調配置

1、驗證基于系統的假設，確認假設是否符合實際情況；2、重現系統中某些異常行為，以解決；3、測試系統當前的運行情況，利用歷史結果分析診斷無法預測的問題；4、模擬更高的負載找出系統隨壓力增加而可能遇到的擴展性瓶頸；5、規劃未來的業務增長，硬件、網絡容量、相關資源；6、測試應用適應可變環境的能力；7、測試不同的硬件、軟件和操作系統配置，證明設備是否配置正確；

對數據庫的基準測試的作用，就是分析在當前的配置下（包括硬件配置、OS、數據庫設置等），數據庫的性能表現，從而找出 MySQL 的性能閾值，并根據實際系統的要求調整配置。【源】

與真實壓力不同：真實的復雜多變；基準測試要求盡可能快執行完成，簡單直接、結果易比較、成本低易行

2.2 策略

針對系統整體：集成式 full-stack

單獨測試 MySQL：單組件式 single-component

推薦整體測試：要正確設置

1、用戶關注的是整體的性能；2、MySQL 并非總是瓶頸；3、更能揭示應用的真實表現

推薦單獨測試：需要數據

1、需比較不同 schema 或查詢的性能；2、針對某個具體問題的測試；3、避免漫長，做短期、快速周期循環

2.2.1 指標

目標：細化為一系列問題，具體問題具體分析

吞吐量：

單位時間內事務處理數，TPC-C、多用戶交互式應用，每秒事務數，每分鐘事務數

響應時間或延遲

測試任務所需的整體時間，平均響時、最小響時、最大和所占百分比；借助圖表

并發性：

測試應用在不同并發下的性能，關注正在工作中的并發操作、同時工作中的線程數 連接數；

web 服務器并發性！= 數據庫的，僅表會話存儲機制數據處理能力；測 web 并發 任意時間有多少并發；

可擴展性

可擴展性：給系統增加一倍工作，理性情況下能獲得兩部的結果；給系統增一倍資源可或 2 倍吞吐量

系統業務壓力可能發生變化：測可擴展性非常必要；該指標對容量規范有用：提供信息來發現應用瓶頸

盡可能收集測試需求，基于需求設計測試，忌只關注部分指標，而忽略其他指標

2.3 方法

要盡可能接近真實應用的情況：

使用全集、數據分布特點、真實分布參數、是否多用戶、匹配用戶行為、多類型、檢查錯誤日志、系統預熱：重啟后多長時間才達到正常性能容量、持續一定時間；

2.3.1 設計、規范

提出問題、目標明確

    標準的基準測試：合適的方案 TPC-H OLTP

    專用的測試：復雜、迭代，獲易還原的生產數據集快照

計劃：參數、結果文檔化、測試詳細記錄

2.3.2 時間

基準測試應運行足夠長的時間，無法確認時間可一直運行，持續觀察知道確認系統已穩定

一個簡單的測試規則：等系統看起來穩定的時間至少 = 系統預熱的時間

2.3.3 獲取系統性能和狀態

盡量多地收集被測系統的信息

best 建目錄、每執行一輪測試創建單獨子目錄，將結果、配置文件、測試指標、腳本和其他相關說明保存其中

需要記錄是數據：

系統狀態、性能指標：CPU 使用率  、磁盤 I /O、網絡流量統計、SHOWGLOBAL STATUS 計數器

合理的間隔，記錄開始時間、利用時間戳、只是收集就好

2.3.4 獲取準確的結果

回答些問題：

是否選擇了正確的基準測試？是否為問題收集了數據？預熱時間是否足夠長？

是否采用了錯誤的測試標準：IO 密集型引用采用 CPU 密集型測試標準來評估性能？

測試結果是否可重復？重測前確保系統狀態一致；對癥測

影響因素：

外部壓力、性能分析、監控系統、詳細日志、周期性作業

注意：

過程中所需資源是專來測試的；測試中盡量少修改參數、通過迭代逐步修改基準測試的參數；認真研究過程中的異常情況并找到原因

2.3.5 運行測試分析結果

自動化：減少人為失誤，Makefile 文件、腳本

測試結果滿足目前需求，簡單運行幾輪測試，看看結果就 OK 了，如結果變化很大，可多運行幾次、或更長時間

結果：

      分析，將數字變成知識，最終的目的是回答在設計時的問題

如何抽象有意義的結果，依賴于如何收集數據，寫腳本分析數據、減少人為失誤、工作量、可重復、文檔化

2.3.6 繪圖重要性

一張圖勝過千言萬語嘛，本來有些知識點寶寶是想畫導圖的，但是么有畫

書中有這么一個語句，分享一下：SHOW FULL PROCESSLIST    SHOW PROCESSLIST 顯示哪些線程正在運行，您也可以使用 mysqladmin processlist 語句得到此信息，如果您有 SUPER 權限，您可以看到所有線程，否則，您只能看到您自己的線程，不使用 FULL 關鍵詞，則只顯示每個查詢的前 100 個字符【源】

2.4 基準測試工具集成測試工具：整個應用

1、ab 是 Apache HTTP，每秒最多可處理多少請求【參考】【2】

2、http_load：ab 類似更靈活，被設計為對 web 服務器測試，通過一個輸入文件提供多個 URL，隨機選擇進行測試，也可定制，使其按照時間比率進行測試【參考】

3、JMeter，java 程序，可加載其他應用并測試其性能，這個聽不錯的，上面兩個沒有接觸過，不評論

單組件式：測 MySQL，基于 MySQL 的系統性能

1、mysqlslap：mysql5.1 后自帶，模擬服務器的負載，輸出計時信息，可執行并發連接數、指定 sql 語句，否則自動生成 select 語句【參考】

2、MySQL Benchmark Suite（sql-bench）：自帶、5.7 拿掉，基準測試套件，用于不同數據庫服務器上進行比較測試，單線程串行執行，測執行查詢的速度；包含了大量預定義測試，易使用，輕松比較不同引擎或配置的性能測試，CPU 密集型的，結果會顯示哪些類型的操作在服務器上執行更快，缺點：測試數據集小且無法用指定的數據，需要 perl BDB 支持；【參考】

3、Super Smack：MySQL、PostgreSQL, 提供壓力測試和負載均衡，復雜而強大的工具，可模擬多用戶訪問，加載測試數據到庫、隨機數據填充測試表【參考】

4、Database Test Suite：類似某些工業標準測試的工具集，免費 TPC-C OLTP 測試工具

5、sysbench：多線程系統壓測，據影響數據庫服務器性能的因素評估系統的性能，全能測試工具，支持 MySQL、操作系統、硬件的硬件測試【參考】【2】

MySQL 的 BENCHMARK() 函數：測試特定操作的執行速度，參數可以是需要執行的次數或表達式（任何標量表達式）

2.5 案例

此處省略 n 字

2.6 總結

終于等到你~ 音樂起；建議至少要熟悉 sysbench，如何使用 oltp（比較不同系統性能）和 fileio 測試；經常執行基準測試，制定一些原則很必要，選擇合適的測試工具、建立腳本庫，收集信息分析結果，熟練一種繪圖工具；

以上是“MySQL 如何測試”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！

向 AI 問一下細節