MySQL基準測試

為什麼很多人在新機器上線後不想做基準測試,無非是繁瑣,耗時, 以及很難度量. 不是非常標準化的採購安裝部署,主機總難免有些缺陷, 所以,如果有一個腳本,可以把cpu,磁碟,網路,資料庫 都預先壓測一遍,就可以省事多了.

我寫下一些測試指引,方便大家構建 MySQL的測試模型:

1. 當我們選擇硬體的時候,我們需要考慮到各項成本,對於項目風險,開發成本,維護成本比較難以衡量,而計算機性能相對來說是更好限定和比較,所以考慮建立一個MySQL的基準測試模型;

2. 單個工具產品的基準測試,主要用於對比版本和衡量軟硬體調整的效果,對於整個應用系統的測試沒有什麼參考意義,應用系統基準測試模型會比單個MySQL測試模型更全民準確;

3. 如果是ssd盤,建議文件最大空間不超過總空間的85%,以避免ssd硬碟空間佔比可能帶來的性能下降;

4. 除了考慮吞吐率(TPS),還需要考慮響應時間(response time);

5. 只測試innodb,不對比myisam,因為生產環境不建議使用myisam,myisam引擎的表崩潰後數據文件會損壞;

6. 衡量MySQL性能需要考慮諸多因素,包括但不限於以下一些因素:

* 硬體:cpu速度,cpu架構,cpu個數,cpu核數,匯流排速度,內存訪問速度,裸設備io性能,raid卡,磁碟條帶,塊大小,網路設備,io調度演算法,

* os: 原生api文件性能,線程,鎖,內存

* 客戶端連接次數

* 資料庫伺服器處理任務的線程個數.

* 資料庫設計

* 數據量

* 應用類型

* 數據訪問模式 : 一般來說我們的應用熱點數據較小,讀原大於寫.如果你的應用熱點數據比較大,訪問各種數據比較分散,比較均勻,那麼這種測試更考驗了資料庫的原始性能)

* 資料庫版本: 社區版 or 企業版 or 其他非官方版本

* 引擎 : 如二進位包自帶的innodb 和 innodb plugin的對比.

* 資料庫配置. 比如numa策略,pagesize大小, 獨立表空間 or 共享表空間, 順序訪問和隨機訪問文件的分布, buffer pool 以及其他一些影響重大的參數.(略)