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

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

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

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

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

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

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

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

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

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

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

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

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