mysql基礎測試，mysql基礎
測試原因
為什麼需要做性能測試
- 模擬比當前系統更高的負載，找出性能瓶頸
- 重現線上異常
- 測試不同硬件軟件配置
- 規劃未來的業務增長
測試分類
性能測試的分類
設備層的測試
業務層測試
數據庫層的測試
- 什麼情況下要做Mysql的測試
-
- 測試不同的Mysql分之版本
- 測試不同的mysql版本
- 測試不同的mysql參數搭配
mysql測試分類
- CPU Bound --全內存的測試，測試的數據遠小於配置的內存；這樣就可以不用因為磁盤IO的性能不同，而影響測試結果。
- IO Bound-- 測試的數據量遠大於內存，這就有大量的數據從磁盤IO讀取寫入；
4小類：
- 寫入測試
- 更新測試
- 純度測試
- 混合模式（根據業務不同）
常用的測試工具
- 開源的mysql性能測試工具
-
- sysbench
- tpcc-mysql
- mysqlslap
- 針對業務編寫性能測試工具
-
- blogbench--根據網易博客，的具體業務來做的測試工具
性能測試衡量指標：
- 服務吞吐量
-
- TPS--每秒執行事務的總量
- QPS--每秒執行的請求總量
- 服務響應時間
- 服務並發性---正在工作中的並發操作，或者是同時工作中的線程數或者連接數。例如一個web站點"同時有50000個用戶"訪問，卻可能只有10--15個並發請求到mysql數據庫，此時並發數只有10--15。
- 可擴展性---------------簡單來說，給系統增加一倍的資源（比如兩倍的CPU數），就可以獲得兩倍的吞吐量。當然，同時性能（響應時間）也必須在可以接受的范圍內。大多數系統是無法做到如此理想的線性擴展的。
測試方法
設計基准測試的常見錯誤：
- 使用真實數據的子集而不是全集。
- 與真實用戶行為不匹配。
- 沒有檢查錯誤。-----------測試中遇到不是預期結果，就應該檢查錯誤日志，這時基本要求。
- 忽略了系統預熱的過程----系統重啟後，緩存是沒有數據的，這時測試與實際情況不符，實際很可能是 緩存中已經有很多數據。
- 測試時間太短
1 測試規劃：
- 記錄測試數據
- 系統配置的步驟
- 如何測試的步驟
- 分析結果
- 預熱的方案
應該建立將參數和結果文檔化的規范，每一輪測試都必須進行詳細記錄
2 基准測試應該運行多長時間
一個簡單的測試規則，就是等系統看起來穩定的時間至少等於
系統預熱的時間。
基准測試應該運行足夠長的時間。
如果沒有實際去完成准確完整的基准測試，那麼已經花費的所有時間都是一種浪費。有時候要相信別人的測試結果，這總比做一次半拉子的測試來得到一個錯誤的結論要好。
3 獲取系統性能和狀態
需要記錄的數據包括系統狀態和性能指標：
- cpu使用率
- 磁盤I/O
- 網絡流量統計
- show global status 計數器等
使用腳本對這些數據進行收集。
基於mysql的默認配置的是沒有什麼意義，因為默認配置是基於消耗很少內存的極小應用的。
4 運行基准測試並分析結果
自動化基准測試，是個不錯的方案。可以是一個makefile或者一組腳本。
要盡可能地使用所有測試過程都自動化，包括數據裝載，系統預熱，執行測試，記錄結果。等。
多次測量
5 繪圖的重要性
通過圖形可以立刻發現一些問題，而這些問題在原始數據中卻很難被注意到。
在執行基准測試的時候要盡可能收集更多的細節數據，然後將數據繪制成圖形，這樣可以幫助快速地發現問題。
gnuplot或者R繪圖；
測試工具
Sysbench
- 業界較為出名的性能測試工具
- 可以測試磁盤，CPU，數據庫
- 支持多種數據庫：oracle，DB2，MYSQL
- 需要自己下載編譯安裝
- 建議版本：sysbench0.5
sysbench,不僅用來測試數據庫的性能，也可以測試運行數據庫的服務器的性能。
強烈建議熟悉sysbench測試，在mysql用戶的工具包中，這應該是最有用的工具之一。
- sysbench 的cpu基准測試
- sysbench 的文件I/O基准測試
- sysbench 的OLTP基准測試
sysbench 其他的基准測試，但和數據庫性能沒有直接關系。
- 內存-----測試內存的連續讀寫性能
- 線程-----測試線程調度器的性能。
- 互斥鎖---測試互斥鎖性能。
- 順序寫---測試順序寫的性能。
Tpcc-mysql
- TPC-C是專門針對聯機交易處理系統（OLTP系統）的規范
- Tpcc-mysql由percona根據規范實現
TPCC流程
更能模擬線上業務
使用該測試工具：需要創建數據和表結構，加載數據，執行測試三個步驟。
benchmark()
mysql的benchmark():可以測試某些特定操作的執行速度。
mysql> set @input := 'hello world';
Query OK, 0 rows affected (0.00 sec)
mysql> select benchmark(1000000,MD5(@input));
+--------------------------------+
| benchmark(1000000,MD5(@input)) |
+--------------------------------+
| 0 |
+--------------------------------+
1 row in set (1.45 sec)
mysql> select benchmark(1000000,SHA1(@input));
+---------------------------------+
| benchmark(1000000,SHA1(@input)) |
+---------------------------------+
| 0 |
+---------------------------------+
1 row in set (1.40 sec)
雖然benchmark（）函數用起來很方便，但是不適合用來做真正的基准測試，因為該函數只是簡單地返回服務器執行表達式的時間，不會涉及分析和開銷，等因素。
而且表達式必須像這個例子一樣包含用戶定義的變量（input），否則會多次執行同樣的表達式會因為系統緩存命中而影響結果。
具體測試實踐，請看sysbench實踐，tpcc-mysql實踐；
總結
- 四小類:寫入測試，更新測試，純度測試，混合模式
- 性能測試衡量指標：
-
- 服務吞吐量
-
- TPS--每秒執行事務的總量
- QPS--每秒執行請求的總量
- 服務響應時間
- 服務並發性
- 設計測試常見錯誤：
-
- 使用數據子集而不是全集，
- 與真實用戶行為不匹配，
- 沒有檢查錯誤，
- 忽略了系統預熱過程，測試時間太短；
- 測試方法
-
- 測試規劃：
-
- 記錄測試數據，
- 系統配置步驟，
- 測試步驟，
- 分析結果，
- 預熱方案；
- 測試時間：測試應該運行足夠長的時間，至少等於系統預熱的時間。
- 獲取系統性能和狀態：cpu，IO,網絡流量，mysql狀態計數器；
- 運行測試：自動化測試包含：數據裝載，系統預熱，執行測試，記錄結果。
- 繪圖分析：直觀的發現問題；
- 測試工具：sysbench,tpcc-mysql,benchmark()
- 測試小結：
-
- IO Bound測試數據量要遠大於內存，cpu Bound測試數據量要小於內存
- 測試時間建議大於60分鐘，減小誤差；有系統預熱時間；
- Sysbench更傾向於測試Mysql性能，Tpcc更接近於業務
- 運行測試程序需要同時監控機器負載，Mysql各項監控指標
