本文來自微信公眾號“twt企業(yè)IT社區(qū)”，作者/白鱔（徐戟），南京基石數(shù)據(jù)技術(shù)有限責(zé)任公司技術(shù)總監(jiān)，在軟件開發(fā)、系統(tǒng)運(yùn)維、信息系統(tǒng)優(yōu)化、信息系統(tǒng)國產(chǎn)化替代等領(lǐng)域從事技術(shù)研究近30年，曾主持開發(fā)了國內(nèi)首套電信級聯(lián)機(jī)實時計費(fèi)系統(tǒng)、國內(nèi)首套三檢合一的檢驗檢疫管理系統(tǒng)、銀行綜合大前置平臺（IPP）等大型系統(tǒng)。著有《Oracle RAC日記》、《Oracle DBA優(yōu)化日記》和《DBA的思想天空》等技術(shù)專著。信息無障礙研究會專職顧問，深圳市鯤鵬產(chǎn)業(yè)聯(lián)盟高級顧問，Oracle ACE，POSTGRESQL ACE DIRECTOR。
一個朋友打電話來討論，說他們在做國產(chǎn)數(shù)據(jù)庫測試的時候，原本一個場景某數(shù)據(jù)庫跑出來的性能與他們的預(yù)期差不多，不過數(shù)據(jù)庫廠商不滿意，于是上去調(diào)整了一通，居然性能大幅提升，并且遠(yuǎn)超出他們對產(chǎn)品的理解。實際上做國產(chǎn)數(shù)據(jù)庫的對比測試是一件十分不容易的事情，往往想獲得一個較為公正的結(jié)果，但是總是覺得被廠家牽著鼻子走。作為一個最近這十多年來參加過多次數(shù)據(jù)庫基準(zhǔn)測試和選型測試的我，今天就聊聊這個話題吧。
既然是對比測試，那么公平是第一位的，而針對現(xiàn)在數(shù)據(jù)庫架構(gòu)十分復(fù)雜，差異性很大，這種情況下，要公正十分困難，在第一個環(huán)節(jié)，底層硬件配置上就十分困難，有些時候只能使用等價配置。前陣子有個測試，參測的其他數(shù)據(jù)庫都是分布式數(shù)據(jù)庫，數(shù)據(jù)都是可以存儲在本地的SSD盤上的，不過有一個參測廠商是使用共享存儲讀寫分離架構(gòu)的，那么就必須給他們提供集中式存儲。而如果提供集中式存儲，那么硬件環(huán)境就又不相同了。讓分布式數(shù)據(jù)庫也使用集中式存儲？分布式數(shù)據(jù)庫廠商對集中式存儲的性能又提出了疑義。最后幸虧是后來那個廠家退出了，這件事才圓滿解決了，否則我都有點(diǎn)蒙圈。
測試中第二件讓人疑惑的事情就是能否讓數(shù)據(jù)庫廠商來操作測試或者操作測試環(huán)境。以我多年的經(jīng)驗來看，如果能夠不讓廠家接觸測試環(huán)境，盡可能不要讓他們接觸。以前做基準(zhǔn)測試的時候，IBM/HP等參加測試能力很強(qiáng)的企業(yè)都有十分豐富的應(yīng)對此類測試的經(jīng)驗，別的廠商和他們一起測試，絕對不是在參加一個公平的測試?，F(xiàn)在某些國產(chǎn)數(shù)據(jù)庫廠商已經(jīng)把IBM等的精髓學(xué)得差不多了，和他們一起玩，防不勝防。也有朋友擔(dān)心不讓廠家接觸環(huán)境，會不會因為優(yōu)化不到位而導(dǎo)致某些廠家的測試結(jié)果不客觀呢？其實這一點(diǎn)容易解決，廠家可以旁觀，或者對測試結(jié)果提出疑問，并且根據(jù)采集到的監(jiān)控數(shù)據(jù)提出問題點(diǎn)，不過盡可能不要讓廠家直接操作系統(tǒng)。否則就會出現(xiàn)我文章前面講的場景，不知道廠家做了啥，系統(tǒng)莫名其妙的大幅提升了。
第二個問題其實引出了第三個問題，就是哪些對數(shù)據(jù)庫的調(diào)整是不允許的。在對比測試時，有些廠商為了獲得好成績，無所不用之極。比如把REDO/UNDO/TEMP放入內(nèi)存盤中，開啟異步提交，關(guān)閉集群延時檢查等。在優(yōu)化器上還會采用關(guān)閉HASH JOIN，強(qiáng)制啟用結(jié)果緩沖等。我們的原則是，所有不能在生產(chǎn)系統(tǒng)中使用的配置和參數(shù)是堅決不允許在測試中使用的。不過對于國產(chǎn)數(shù)據(jù)庫，這些you點(diǎn)麻煩，因為我們不知道哪些參數(shù)是不允許使用的。不過我們可以將數(shù)據(jù)庫默認(rèn)安裝后的參數(shù)與配置保存一份，測試過程中再采集幾份，作為今后分析測試結(jié)果有消息的證據(jù)。
第四個問題是在測試過程中是否允許改寫SQL語句，不同的數(shù)據(jù)庫，其優(yōu)化器和SQL引擎是有差異的，有些在ORACLE上能跑并且跑得不錯的SQL，可能在國產(chǎn)庫上跑得很差甚至無法執(zhí)行。這一點(diǎn)其實很常見，也并不能說國產(chǎn)數(shù)據(jù)庫就不行。如果通過等價改寫能夠解決這個問題，那么我們應(yīng)該能夠承認(rèn)這個測試結(jié)果。只不過我們要記錄一下，經(jīng)過了等價改寫。既然判斷是等價改寫，我們就需要嚴(yán)格比對輸出的結(jié)果是否正確。
第五個問題是，是否允許在中途調(diào)整數(shù)據(jù)庫參數(shù)或者表的分區(qū)分布。這一點(diǎn)嚴(yán)格上說應(yīng)該不允許，不過對于一些較為復(fù)雜的測試，特別是在分布式數(shù)據(jù)庫上的測試，剛開始的分布策略設(shè)計可能不夠合理。有些時候做些調(diào)整，會有很大的性能提升。不過要注意的一點(diǎn)是，如果做了這方面的調(diào)整（哪怕是修改了一個參數(shù)），所有的已經(jīng)測試過的測試項都必須重新測試一遍，并將以前所有的測試結(jié)果作廢。為了確保測試進(jìn)度，這種調(diào)整一定要做限制，比如每個廠商只允許調(diào)整一次。
第六個問題，SQL性能測試最好帶有背景壓力。我們經(jīng)常會遇到測試時候性能不錯，實戰(zhàn)時候差強(qiáng)人意的情況。這是因為SQL在測試環(huán)境是獨(dú)立運(yùn)行的，沒有任何背景壓力干擾，高可用切換場景或者故障自愈場景也是如此，在沒有一定負(fù)載下，都是很正常的，帶一定的背景負(fù)載很可能就不同了。我們以前曾經(jīng)見過某國產(chǎn)數(shù)據(jù)庫，跑200并發(fā)BENCHMARK的時候性能不錯，不過如果連上10000個空會話，再跑BENCHMARK，性能要打不少折扣。這可能是數(shù)據(jù)庫在維護(hù)會話列表的代碼上沒有做好優(yōu)化導(dǎo)致的，雖然是個小問題，不過如果沒有注意，到了生產(chǎn)環(huán)境還是會引發(fā)問題的。
第七個問題是要關(guān)注SQL執(zhí)行的穩(wěn)定性問題，如果你的應(yīng)用場景是對小SQL的執(zhí)行延時有要求的，比如銀行的核心交易系統(tǒng)，現(xiàn)在網(wǎng)聯(lián)對核心交易超時的監(jiān)控十分嚴(yán)格，那么SQL執(zhí)行的穩(wěn)定性就十分關(guān)鍵了。同樣一條SQL是否執(zhí)行起來忽快忽慢，相同的SQL是否經(jīng)常出現(xiàn)多次執(zhí)行執(zhí)行計劃不同，這也應(yīng)該我們關(guān)注的。如果時間充裕，最好多跑幾遍，最后算個標(biāo)準(zhǔn)差出來，做個比對。
實際上很多時候測試往往并不能對我們的決策產(chǎn)生多大的影響，有可能IT部門辛苦幾個月干完了測試，突然某廠家與企業(yè)高層簽署了戰(zhàn)略合作協(xié)議，那活就白干了。不過測試中發(fā)現(xiàn)的問題，積累的經(jīng)驗，今后運(yùn)維中還是有點(diǎn)價值的。
