在數(shù)據(jù)庫國產(chǎn)化的時代里很多朋友染上了性能焦慮癥，就怕一旦從Oracle遷移到國產(chǎn)數(shù)據(jù)庫后性能有問題。存在這種顧慮是沒問題的，因為從當(dāng)前最優(yōu)秀的數(shù)據(jù)庫產(chǎn)品中遷移到任何一種其他數(shù)據(jù)庫，這種顧慮都是應(yīng)該有的。不過由于大多數(shù)人對性能的理解過于片面，因此某些顧慮變成了不合時宜的焦慮。因為很多人不知道該如何來評價一個系統(tǒng)的性能，進而無法了解我們需要用什么樣的數(shù)據(jù)庫系統(tǒng)來適配某個應(yīng)用場景。

在這里我沒有簡單的說數(shù)據(jù)庫，而是用了“數(shù)據(jù)庫系統(tǒng)”這個詞，因為性能與容量都不僅僅取決于一個RDBMS，而是一個系統(tǒng)性的問題。很多人正是因為對“性能”和“容量”問題的認知不足，因此產(chǎn)生了極大的焦慮。對于不同的應(yīng)用系統(tǒng)與應(yīng)用場景，性能的要求是不同的，性能并不等于 TPMC，也并不是等于并發(fā)訪問的性能，也不等于某條特定SQL的執(zhí)行效率。

這些年我遇到最多的是“TPMC焦慮癥”，在他們眼里最令人焦慮的是TPMC指標(biāo)。面對tpcc官網(wǎng)上動輒數(shù)百萬上千萬的數(shù)據(jù)，再看看自己的測試環(huán)境里可憐的幾十萬的指標(biāo)，感到十分沮喪。前陣子有朋友和我說，他們目前十分難焦慮國產(chǎn)數(shù)據(jù)庫測試的事情，因為在他們的環(huán)境中，無論如何優(yōu)化都跑不出數(shù)據(jù)庫廠商標(biāo)稱的TPMC。他們擔(dān)心這是否會引起他們的系統(tǒng)上線后，性能無法達到要求。

實際上TPMC僅僅是一種基準(zhǔn)，如果要在一個環(huán)境中跑出超高的指標(biāo)，那么需要對系統(tǒng)做各種配合TPMC場景的優(yōu)化，而這種場景往往與用戶的應(yīng)用場景無關(guān)，因此TPMC指標(biāo)的高低并不說明今后你的系統(tǒng)性能就會好。節(jié)前和一個用戶聊天，他就說一些國產(chǎn)數(shù)據(jù)庫好像TPMC也不見得比Oracle差，不過用起來感覺應(yīng)用性能差了不少，就是這個原因。

另外一個我們需要了解的是TPMC官方發(fā)布的指標(biāo)與我們或者某個數(shù)據(jù)庫廠商自己跑出來的TPMC完全沒有可比性，因為官方的TPMC指標(biāo)的判別標(biāo)準(zhǔn)十分嚴(yán)格，對每個交易的延時都有要求，而我們的測試很難達到如此苛刻的要求，甚至不知道還有這些要求。

另外一個需要我們注意的是，實際上大多數(shù)系統(tǒng)并不需要如此高的TPMC。比如說某個銀行需要實現(xiàn)每秒鐘3000筆核心交易，如果我們認為核心交易與BENCHMARK測試的場景消耗類似的話，那么折算成TPMC，大約是18萬，哪怕高峰期是平均值的5倍，也不到100萬。是不是看上去很LOW呢？實際上這可能就是我們的真實需要。

既然數(shù)據(jù)庫的性能并不能通過TPMC很好地表現(xiàn)出來，那么我們該如何看待數(shù)據(jù)庫的性能呢？實際上對于大多數(shù)應(yīng)用系統(tǒng)來說，并發(fā)事務(wù)的性能都不是個問題，我們應(yīng)該把目光放到其他的一些方面。比如：從Oracle遷移過來的兼容性與數(shù)據(jù)安全性；系統(tǒng)部署與配置的簡易性；系統(tǒng)高可用方案的完備性與可靠性；系統(tǒng)備份恢復(fù)的便捷性與可用性；異構(gòu)數(shù)據(jù)庫之間數(shù)據(jù)交換的支持能力；字符集與時區(qū)的準(zhǔn)確性；與云平臺的IT基礎(chǔ)設(shè)施的適配性；數(shù)據(jù)庫運維的可觀測性；等等，等等。

除此之外，如果我們的應(yīng)用確實對SQL的響應(yīng)時間特別敏感，比如一些關(guān)鍵的交易型業(yè)務(wù)，如果類似TPMC的并發(fā)交易能力不是問題，那么其他一些數(shù)據(jù)庫的基本性能，可以關(guān)注一下。

首先是單表全表掃描的效率，包括并行掃描和串行掃描的效率。全表掃描是應(yīng)用系統(tǒng)中很常見的操作，也是數(shù)據(jù)庫中最簡單的操作，這個掃描性能基準(zhǔn)能否滿足你的一些業(yè)務(wù)需求十分關(guān)鍵，因為在某種硬件條件下，這個基準(zhǔn)是無法提升的。因此這個指標(biāo)一定要能夠達到你的應(yīng)用的及格線要求。在測試這個性能指標(biāo)的時候，要注意測試串行掃描與并行掃描，并對不同的并發(fā)度做一個全面的測試。不同的數(shù)據(jù)庫，因為并行掃描的算法優(yōu)化不同，以及存儲引擎的不同，這方面會有較大的差異。

其次是批量輸出數(shù)據(jù)的效率，這也是應(yīng)用系統(tǒng)中經(jīng)常有的場景，邏輯數(shù)據(jù)導(dǎo)出就是其中的一個場景。數(shù)據(jù)導(dǎo)出也需要測試串行和并行兩種情況。不同的硬件環(huán)境，甚至網(wǎng)絡(luò)環(huán)境都會有很大的差異，因此在做這個測試的時候要確保硬件環(huán)境沒有成為瓶頸。

第三是各種表連接的執(zhí)行計劃與執(zhí)行效率。大多數(shù)多表連接最終都會轉(zhuǎn)化為雙表連接，找出應(yīng)用中最常用的表連接方式，一一進行測試，確定每種連接方式都能用正確的執(zhí)行計劃執(zhí)行，并且效率都能達到你的應(yīng)用的需要。在做這項測試的時候，數(shù)據(jù)最好使用你自己的生產(chǎn)數(shù)據(jù)或者生產(chǎn)數(shù)據(jù)的脫敏和模擬數(shù)據(jù)。

第四種是HINT/OUTLINES的能力測試，HINT是復(fù)雜應(yīng)用系統(tǒng)不可或缺的基礎(chǔ)能力，如果你的業(yè)務(wù)系統(tǒng)較為復(fù)雜，數(shù)據(jù)量也很大，經(jīng)常有多張表關(guān)聯(lián)的SQL，而選擇的數(shù)據(jù)庫產(chǎn)品不具備這個能力，或者這個能力不足，那么就要慎用。我們早期在使用Oracle的時候，也經(jīng)常需要用HINT或者Outlines來糾正錯誤的執(zhí)行計劃，目前的大多數(shù)國產(chǎn)數(shù)據(jù)庫的優(yōu)化器沒有Oracle那么高效，當(dāng)出現(xiàn)錯誤的執(zhí)行計劃不能用表分析來解決或者表分析后也依然存在問題的時候，必須用HINT來解決問題，否則就必須拆分和改寫SQL語句才能解決問題了。

實際上數(shù)據(jù)庫系統(tǒng)的性能與容量除了與數(shù)據(jù)庫本身有關(guān)外，還與數(shù)據(jù)庫運行的環(huán)境有很大的關(guān)系，服務(wù)器、網(wǎng)絡(luò)、操作系統(tǒng)等都是影響性能的重要因素。因此如果發(fā)現(xiàn)了某些測試無法滿足要求，那么我們還可以考慮在你們的企業(yè)IT投資規(guī)模允許的前提下，是不是可以通過提升底層性能來解決當(dāng)前測試時無法達到的一些性能指標(biāo)的問題。有些時候數(shù)據(jù)庫產(chǎn)品本身的性能不足，還是可以通過其他方式來彌補的，綜合成本可能是我們更需要考慮的成本要素。