如果不清楚系統當前的效能，就無法確認某些優化的效果如何。也可以利用歷史的基準測試結果來分析診斷一些無法**的問題。
基準測試可以評估在專案未來的負載下，需要什麼樣的硬體，需要多大容量的網路，以及其他相關資源。這有助於降低系統公升級和重大變更的風險。
例如，通過基準測試，可以發現系統在隨機的併發峰值下的效能表現，或者是不同配置的伺服器之間的效能表現。基準測試也可以測試系統對不同資料分布的處理能力。
比如raid 5還是raid 10更適合當前的系統？如果系統從ata硬碟公升級到san儲存，對於隨機寫效能有什麼幫助？linux 2.4系列的核心會比2.6系列的可擴充套件性更好嗎？公升級mysql的版本能改善效能嗎？為當前的資料採用不同的儲存引擎會有什麼效果？所有這類問題都可以通過專門的基準測試來獲得答案。
通過基準測試來對新系統進行壓測，可以發現了很多錯誤的配置，以及硬體元件的失效等問題。因此在新系統正式上線到生產環境之前進行基準測試是乙個好習慣，永遠不要相信主機提供商或者硬體**商的所謂系統已經安裝好，並且能執行多快的說法。如果可能，執行實際的基準測試永遠是乙個好主意。
測試整個應用系統，包括web伺服器、應用**、網路和資料庫是非常有用的，因為使用者關注的並不僅僅是mysql本身的效能，而是應用整體的效能。
mysql並非總是應用的瓶頸，通過整體的測試可以揭示這一點。
只有對應用做整體測試，才能發現各部分之間的快取帶來的影響。
整體應用的整合式測試更能揭示應用的真實表現，而單獨元件的測試很難做到這一點。
需要比較不同的schema或查詢的效能。
針對應用中某個具體問題的測試。
為了避免漫長的基準測試，可以通過乙個短期的基準測試，做快速的「週期迴圈」，來檢測出某些調整後的效果。
吞吐量指的是單位時間內的事務處理數。這一直是經典的資料庫應用測試指標。常用的測試單位是每秒事務數（tps），有些也採用每分鐘事務數（tpm）。
這個指標用於測試任務所需的整體時間。根據具體的應用，測試的時間單位可能是微秒、毫秒、秒或者分鐘。使用圖表有助於理解測試結果。可以將測試結果繪製成折線圖（比如平均值折線或者95％百分比折線）或者散點圖，直觀地表現資料結果集的分布情況。
併發性的測量完全不同於響應時間和吞吐量。它不像是乙個結果，而更像是設定基準測試的一種屬性。併發性測試通常不是為了測試應用能達到的併發度，而是為了測試應用在不同併發下的效能。
簡單地說，可擴充套件性指的是，給系統增加一倍的工作，在理想情況下就能獲得兩倍的結果（即吞吐量增加一倍）。或者說，給系統增加一倍的資源（比如兩倍的cpu數），就可以獲得兩倍的吞吐量。
規劃基準測試的第一步是提出問題並明確目標。然後決定是採用標準的基準測試，還是設計專用的測試。
然後，針對資料執行查詢。可以建立乙個單元測試集作為初步的測試，並執行多遍。
建立將引數和結果文件化的規範，每一輪測試都必須進行詳細記錄。文件規範可以很簡單，比如採用電子**（spreadsheet）或者記事本形式，也可以是複雜的自定義的資料庫。需要記住的是，經常要寫一些指令碼來分析測試結果，因此如果能夠不用開啟電子**或者文字檔案等額外操作，當然是更好的。
基準測試應該執行足夠長的時間，這一點很重要。有時候無法確認測試需要執行多長的時間才足夠，可以讓測試一直執行，持續觀察直到確認系統已經穩定。下圖是系統磁碟讀和寫吞吐量的時序圖。
在執行基準測試時，需要盡可能多地收集被測試系統的資訊。
mysql基準測試套件
sysbench
高效能mysql 樹 高效能mysql精要
1 explain 中 extra using index 表示覆蓋索引，sql優化中最好能使用覆蓋索引，否則 二級索引 需要回表查詢。所謂覆蓋索引，是指要查詢的列正好是索引，而條件也是這個索引之一 2 where 語句中 條件等於主鍵的 在核心索引層完成，條件等於非索引的，在服務層完成 3 讀索引...
mysql高效能索引 mysql高效能索引（ ）
在開發中，我們知道大多數應用的瓶頸在於sql語句的執行時耗，在這裡並不討論sql語句的安全，僅僅討論高效能sql語句，而與高效能sql語句緊密相連的就是傳說中的 索引。索引 一種工作在儲存引擎端的用於快速找到記錄的一種資料結構。mysql使用索引的方式是 先找到索引的值，再根據索引的值找到資料行。索...
高效能MYSQL（複製）
複製概述 複製解決的基本問題是讓乙個伺服器的資料與其他伺服器保持同步。一台主庫的資料可以同步到多台備庫上，備庫本身也可以被配置成另外一台伺服器的主庫。複製方法 基於行的複製 基於語句的複製。實現 在主庫上記錄二進位制日誌，在備庫重放日誌的方式來實現非同步資料複製。會出現資料不一致，並且無法保證主備之...