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