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

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

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

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

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

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

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

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

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

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

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

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

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