在數(shù)據(jù)庫(kù)國(guó)產(chǎn)化的時(shí)代里很多朋友染上了性能焦慮癥，就怕一旦從Oracle遷移到國(guó)產(chǎn)數(shù)據(jù)庫(kù)后性能有問(wèn)題。存在這種顧慮是沒(méi)問(wèn)題的，因?yàn)閺漠?dāng)前最優(yōu)秀的數(shù)據(jù)庫(kù)產(chǎn)品中遷移到任何一種其他數(shù)據(jù)庫(kù)，這種顧慮都是應(yīng)該有的。不過(guò)由于大多數(shù)人對(duì)性能的理解過(guò)于片面，因此某些顧慮變成了不合時(shí)宜的焦慮。因?yàn)楹芏嗳瞬恢涝撊绾蝸?lái)評(píng)價(jià)一個(gè)系統(tǒng)的性能，進(jìn)而無(wú)法了解我們需要用什么樣的數(shù)據(jù)庫(kù)系統(tǒng)來(lái)適配某個(gè)應(yīng)用場(chǎng)景。

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

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

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

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

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

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

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

首先是單表全表掃描的效率，包括并行掃描和串行掃描的效率。全表掃描是應(yīng)用系統(tǒng)中很常見(jiàn)的操作，也是數(shù)據(jù)庫(kù)中最簡(jiǎn)單的操作，這個(gè)掃描性能基準(zhǔn)能否滿(mǎn)足你的一些業(yè)務(wù)需求十分關(guān)鍵，因?yàn)樵谀撤N硬件條件下，這個(gè)基準(zhǔn)是無(wú)法提升的。因此這個(gè)指標(biāo)一定要能夠達(dá)到你的應(yīng)用的及格線(xiàn)要求。在測(cè)試這個(gè)性能指標(biāo)的時(shí)候，要注意測(cè)試串行掃描與并行掃描，并對(duì)不同的并發(fā)度做一個(gè)全面的測(cè)試。不同的數(shù)據(jù)庫(kù)，因?yàn)椴⑿袙呙璧乃惴▋?yōu)化不同，以及存儲(chǔ)引擎的不同，這方面會(huì)有較大的差異。

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

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

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

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