基準測試（benchmarking）是一種測量和評估軟件性能指標的活動。你可以在某個時候通過基準測試建立一個已知的性能水平（稱為基準線），當系統的軟硬件環境發生變化之后再進行一次基準測試以確定那些變化對性能的影響。這是基準測試最常見的用途。其他用途包括測定某種負載水平下的性能極限、管理系統或環境的變化、發現可能導致性能問題的條件，等等。
基準測試的具體做法是：在系統上運行一系列測試程序并把性能計數器的結果保存起來。這些結構稱為“性能指標”。性能指標通常都保存或歸檔，并在系統環境的描述中進行注解。比如說，有經驗的數據庫專業人員會把基準測試的結果以及當時的系統配置和環境一起存入他們的檔案。這可以讓他們對系統過去和現在的性能表現進行對照比較，確認系統或環境的所有變化。
基準測試通常都是些功能測試，即測試系統的某個功能是否達到了預期的要求。有些性能測試工具可以對系統幾乎所有的方面（從最常見的操作到最復雜的操作，從小負載到中等負載到大負載）進行測試。
大部分程序員只在系統發生了奇怪的事情時才考慮進行基準測試，但我認為定期進行基準測試，尤其是在重大事件（比如系統或環境發生變化）之前和之后進行基準測試更有意義。一定要首先進行一次基準測試以創建基準線。如果沒有基準線作為參照物，在事件發生之后進行的基準測試是不會對你有多大幫助的。
1、優秀基準測試的指導原則
在進行基準測試的時候，有許多好的實踐方法。在這一節里，我將向大家介紹幾個我認為對大家最有幫助的基準測試原則。
首先，應該牢記“事前快照”和“事后快照”的概念。不要等到你對服務器做出修改之后才想起應該進行一次基準測試并把測試結果與你在六個月前建立的基準線進行對比。六個月的時間會發生許多事情！你應該在做出修改之前進行一次測試，做出修改，然后再對系統進行一次基準測試。這可以讓你對三組性能指標進行對比：系統的預期性能、它在修改前的實測性能以及它在修改后的實測性能。你可以發現所發生的事情讓你的改變多少會明顯一些。比如說，假設你的基準測試有一項是度量查詢時間。你在六個月前為某個特定的測試查詢建立的基準線需要花費4.25秒才能完成。現在，你決定修改受測表的某個索引。你在修改之前進行的基準測試得到的結果是15.5秒，而你在修改之后進行的基準測試得到的結果是4.5秒。如果你沒有拍攝事前快照，就不會知道你的修改讓系統的性能有了很大的提高。說不定還會以為你的修改降低了查詢的速度--你也許會因此撤消這次修改，結果返回到執行速度慢的查詢。
雖然這是一個假想的例子，但我希望大家能夠從中注意到以下幾點。首先，如果你是在對某個系統的數據檢索性能執行基準測試，而這個系統的數據量會隨著時間的推移而增長，你必須更頻繁地運行你的基準測試工具才能準確地把握數據量的增長對系統性能的影響。在剛才的例子里，你應該把有關性能指標（比如數據負載量）在事前的測量值當作系統的“正常”指標。
其次，必須保證你的測試對你測量的東西有效。如果你在對某個表的查詢性能進行基準測試，你得到的測試結果只限于應用程序級別，不足以從一般意義上預測系統的性能。一定要把應用程序級別的基準與全局性的性能指標區分開來，這樣才能保證不會得出錯誤的結論。
另外一個與事前概念和事后概念有關的好的實踐方法是，在活動（負載量相對穩定）的有限時間內盡可能多做幾次基準測試，這是為了保證你的測試結果不會受到局部活動（比如臨時出現的進程或高資源占用任務）的影響。我發現重復進行幾十次同樣的基準測試可以把各次測試結果的平均值作為最終的性能指標值。有許多技巧可以得到這些統計結果。有條件的話，你甚至可以使用一個統計包或是你喜歡的適用于統計的電子表格應用程序 來得出基本的統計數字。
注解：有些基準測試工具有自己的統計分析包，但MySQL Benchmark Suite沒有。
我認為最有用的建議是每次只修改一個地方。一次修改多個地方并不是不可以，但這樣你就不能期望從基準測試結果里得出什么有意義的結論。經常會發生這樣的事：你修改了6個地方，其中之一產生的負面影響掩蓋了另外幾個的正面效果，剩下的一兩個對性能沒有任何影響。只有每次修改一個地方，你才能準確地判斷出它對系統性能的影響是負面的、正面的還是沒有影響。
還有，只要有可能，就應該使用實際數據來進行基準測試。人工生成的測試數據怎么說也會有一些規律可循，那樣得到的測試結果往往不能反映實際情況，某些特定的功能（比如邊界值和范圍檢查等）可能永遠也得不到測試。如果你的數據變化很頻繁，你應該選擇某個時刻為它們“拍攝”一張快照，然后使用這張快照來進行每一次測試。不過，這么做雖然能夠保證使用真實的數據來測試性能，可是隨著數據量的增長也許無法測試出系統性能的下降。
最后，在解讀基準測試結果和管理預期目標時，一定要讓你的目標有現實意義。如果你想改善系統在某種特定條件下的性能，在確定目標前首先要把已知的后果弄清楚。比如說，如果你想知道把網絡接口的傳輸速度提高100倍對系統性能會產生哪些影響，就必須先弄清楚你的服務器將不能按照比現在快100倍的速度發送和接收數據。在這類場合中，你必須綜合考慮硬件的性價比和硬件可能帶來的性能改善。換句話說，你的服務器的執行速度應當提高幾個百分點，這樣就為你省了錢（或說增加了收入）。
如果在做過仔細評估之后預計你的網絡性能只要提高10%就可以做到收支平衡甚至贏利，那就把這個數字作為你的目標好了。如果基準測試結果表明你得到了這么大（或更好）的改善，就去找老板談談加薪的事吧；如果基準測試結果表明你沒有得到這么大的改善，去建議老板把新硬件退回去（也可以順便談談加薪的事，因為你讓他省錢了）。不管是哪種情況，你的報告都有充分的依據，即你的基準測試結果。
2、對數據庫系統進行基準測試
基準測試在很多領域都非常重要。但基準測試與數據庫服務器到底有什么關系呢？答案包括很多方面。
對數據庫服務器進行基準測試可以在許多不同的層次上進行。最常見的是針對數據庫模式的改動而進行的基準測試。專門針對某個表的基準測試比較少見（雖然你可以這么做）。人們更感興趣的是在改變了數據庫的結構之后，其性能會受到什么樣的影響。
人們的這種關心在剛開始使用一個新的應用程序或一個新的數據庫時表現得尤為明顯。此時，你可以設計好幾種數據庫模式并填充數據，然后編寫一些基準測試程序來模仿所推薦的系統。嘿，這也是一種測試驅動的開發行為！通過創建多個數據庫模式并進行基準測試，甚至可能會多次重復這些改動，你很快就可以確定哪套模式最適合你設計的應用。
有時候，對數據庫系統進行基準測試還有一些特殊的目的。比如說，你想知道數據庫系統在不同的負載情況或不同的系統環境下會有怎樣的性能表現。那么，除了進行事前和事后的基準測試去了解對環境所做的改變會產生多大的不同，還有什么方法更能證明你新安裝的RAID設備將大幅改善系統的性能呢？是的，一切都是圍繞成本進行考慮，基準測試工具可以幫助你管理好數據庫系統的成本。