基準測試是唯一方便有效的、可以學習系統在給定的工作負載下會發生什麼的方法。基準測試可以觀察系統在不同壓力下的行為，評估系統的容量，掌握哪些是重要的變化，或者觀察系統如何處理不同的資料。
基準測試的乙個主要問題在於其不是真實壓力測試。基準測試施加給系統的壓力相對於真實壓力來說，比較簡單。
我們只能進行大概的測試，來確定系統大致的餘量有多少。基準測試要盡量簡單直接，結果之間容易相互比較，成本低切易於執行。
針對整個系統的整體測試（整合式）
單獨測試mysql（單元件式）
針對整個系統做整合式測試，而不是單獨測試mysql的原因如下：
針對於以下情況，可以只測試mysql：
吞吐量 單位時間內的事務處理數。（標準測試tpc-c） 這類基準測試主要針對oltp的吞吐量，適用於多使用者的互動式應用。常用的測試單位是每秒事務數（tps），有些也採用每分鐘事務數（tpm）
響應時間或延遲 用於測試任務所需的整體時間。根據具體應用，測試的時間單位可能是微秒、毫秒或者分鐘。根據不同的時間單位可以計算出平均響應時間、最小響應時間、最大響應時間和所佔百分比。 使用圖表有助於理解測試結果。
併發性 併發性基準測試需要關注的是正在共組哦中的併發操作，或者是同時工作中的執行緒數或者連線數。當併發性增加時，需要測量吞吐量是否下降，響應時間是否變長。併發性測量完全不同於響應時間的吞吐量。它不像是乙個結果，更像是設定基準測試的一種屬性。
可擴充套件性 在系統的業務壓力可能發生變化的情況下，測試可擴充套件性就非常必要了。可擴充套件性是指給系統增加一倍的工作，在理想情況下就能獲得兩倍的結果。或者說，給系統增加一倍的資源（比如兩倍的cpu數），就可以獲得兩倍的吞吐量。當然，同時效能也必須在可以接受的範圍內。（大多數系統是無法做到如此理想的線性擴充套件的。隨著壓力的變化，吞吐量和效能都可能越來越差）。
規劃基準測試的第一步是提出問題並明確目標，然後決定是採用標準的基準測試還是設計專用的測試。
如果採用標準的基準測試，應該確認了選擇合適的測試方案。設計專用的基準測試是很複雜的，往往需要乙個迭代的過程。首先需要獲得生產資料的資料集快照，並且該快照很容易還原，以便進行後續的測試。
針對資料執行查詢，可以建立乙個單元測試集是作為初步的測試，並執行多遍。但是這和真實的資料庫環境還是有差別的。更好的辦法是選擇有個代表性的時間段，記錄生產系統上的所有查詢。如果時間段選得比較小，則可以選擇多個時間段。這樣有助於覆蓋整個系統的活動狀態。
可以在不同級別記錄查詢，可以記錄web伺服器上的http請求，也可以開啟mysql的查詢日誌。
即使不需要建立專用的基準測試，詳細地寫下測試規則也是必需的。測試可能要多次反覆執行，因此需要精確地重現測試過程。測試規劃應該記錄測試資料、系統配置的步驟、如何測量和分析結果，以及預熱的方案等。
應該建立將引數和結果文件化的規範，每一輪測試都必須進行詳細記錄。需要記住的是，經常要寫一些指令碼來分析測試結果，因此能夠不用開啟電子**或者文字檔案等額外操作，當然是更好的。
已有的整合式測試工具如下：
已有的單元件測試工具如下：
mysql基準測試例項 mysql基準測試
toc 單位時間內所處理的事務數 tps 單位時間內所處理的查詢數 qps 響應時間 平均響應時間,最小響應時間,最大響應時間,各時間所佔百分比 併發量 同時處理的查詢請求的數量 併發量不等於連線數 正在工作的併發的操作或同時工作的數量 工具 mysqlslap mysql自帶的 特點 可以模擬伺服...
mysql 基準測試指令碼 MySQL基準測試
常見指標 tps transaction per second qps query per second 響應時間 併發量步驟 計畫和設計基準測試 準備基準測試及資料收集指令碼 容易忽略的問題 使用生產環境資料時只使用了部分資料 在多使用者場景中，只做單使用者的測試 在單伺服器上測試分布式應用 反覆...
mysql 基準測試報告 Mysql基準測試
一 基準測試 基準測試的作用 了解當前系統的效能，建立mysql伺服器效能基準線 為之後的效能優化提供乙個超始線 模擬比當前系統更高的負載，找出系統的擴充套件瓶頸，為系統擴充套件與優化提供參考條件 測試不同的硬體 軟體和作業系統配置 證明新的硬體裝置是否配置正確和是否是最優配置 基準測試可以分為整合...