為什麼我總和效能指標相差很遠？

      我經常看到類似這樣的標題某某DB比原生MySQL快N倍。原生的快多少倍其實我覺得不是太重要，甚至是不是比原生的MySQL PG快這也不好說。我們退一萬步認為這個假設成立，實際也用不出這個效果。我今天來講講為什麼。首先一個正常的主流的關係型資料庫發揮出每秒幾萬次，乃至十幾萬次的讀，和幾千次寫一點問題都沒有。這還是在單機的情況下，所以我也一再強調如果業務沒有達到單機的瓶頸，就單機（可以主從保障高可用）就好了。不要分庫分表，當然單機了甚至單機上的各個schema相互訪問一下就好了，不用介面，不用MQ了。一致性都有保障，開發工作量減少非常多。但是為什麼我們經常會遇到瓶頸？這裡分析一下官方的資料怎麼來的？現實的資料怎麼來的？

    官方資料庫（也稱實驗室資料），是在理想環境下，按照標準的設計和標準的規範壓測的。我猜TPCC也是這樣吧？我沒參與過，只能猜。實際資料可能過於完美，但是我們可能沒有理想的實驗室，但是如果也按照標準的設計和標準的規範來做，我覺得打個8-9折還是可以的。

   但是真實情況呢？又是不忍直視啊。似乎MySQL、PG甚至Oracle的原廠都太過理想化我們的實際開發水平了。比如Oracle覺得我們不應該有直接路徑讀，MySQL以前覺得我們單表或者兩表關聯，取幾條資料，巢狀迴圈最好為什麼要hash join？但是實際上我國現狀可能除了大廠的那些開發做得好些，一般的企業很多開發都是全表查詢。索引？索引是什麼？不清楚。咦，我怎麼越查越慢？放快取吧。分庫吧。分表吧。 資料同步吧。訊息佇列吧。可能官方賣家秀是資料是每秒10萬次，而買家秀是100秒1次。這就差了1000萬倍的效能。所以官方想的很好，宣傳的可能有點誇大，但是實際用下來非常拉胯。

  但是這個鍋誰背。我以前一直舉例，考駕照時候手動擋的。坡道起步，五檔起步。熄火了是怪車還是怪坡？

  通常來說一個併發場景。比如60秒有600個請求，那麼最差的要求，每次請求不得超過0.1秒為好。因為一個資料庫不太可能就處理一個場景。如果頻次X單次時間等於併發區間的話，那麼說明CPU基本很忙了。

  所以我們各種效能基本還是依靠SQL質量。那各種資料庫能不能在應用程式碼很差的時候還能發揮出實驗室效果或者接近實驗室效果呢。很少吧。我目前看到的例如Oracle in-memory還有tidb的tiflash的設計以及MySQL的heatwave都是從設計上用硬體去抗掉了。這些我真正用過的僅有in-memory，真的是全表聚合一億條，也就一秒不到。而這個還是我虛擬機器效果，不是一體機的效果。所以我覺得真正能抗爛程式碼的效能才是真的效能。

比如： 我想起來以前看到TimesTen分散式叢集的介紹（我只用過單機的）

就這些資料而言，基本屬於驚人的效能。我覺得大家都不太相信，我其實覺得如果我們有條件使用的話，8-9成的效能是能發揮的出來的。因為他是硬體可以去抗效能的。

   結論就是之所以和宣傳的效能天差地別，就是沒有按照規範設計和實施。除非產品就是結合硬體去抗爛程式碼。