MYSQL與PG為啥非要爭個誰好誰壞呢？

MYSQL和PG是影響力最大的兩個開源關系型數據庫，這些年來圍繞這二者誰更好的問題，一直是十分激烈的。目前的大多數創新的數據庫產品和國產數據庫產品都或多或少地與這兩個數據庫有些淵源。因此也具有把這兩個數據庫分出個高下來的動力。實際上不僅僅在國內，國外PG派和MYSQL派也經常吵得不可開交。根據database Journal的統計，PG數據庫全球市場占有率大約為15%+，Mysql的全球市場占有率大約為44%+，在全球占有率方面Mysql絕對領先。不過在美國的最新統計，PG的市場占有率高達33%，反超了MYSQL的31%。我不知道這個數據是不是靠譜，實際上數據庫市場占有率的國別差異也很大，在英國，MYSQL 以6.75%小幅度領先于PG的5.74%。和幾年前的數據對比，雖然全球范圍內MYSQL的市場占有率還遠高于PG，不過二者的差距在逐漸縮小。

實際上數據庫好壞之爭已經幾十年了，爭來爭去企業選擇數據庫產品最終還是要看應用場景、商務條件與企業的喜好或者說相關決策者的喜好。前兩年在一家互聯網金融公司，他們的CIO問我MYSQL和PG數據庫，該如何選擇。他們以前用MYSQL數據庫，數據量大了以后，SQL編寫就要十分小心，否則容易出現性能問題。而出現過性能問題的SQL語句，他們測試了一下，在PG上跑出來的性能還可以。因此他們公司內部就有些想把數據庫換成PG的想法。

我分析了一下他們的應用場景，確實隨著數據量的增加，一些多表關聯的復雜查詢會出現性能問題，就這一點來說，換PG數據庫也說的過去。不過根據他們應用的特點、客戶的運維能力以及他們售后服務的投入，再進行分析。我們最終得出了截然不同的答案，他們還是繼續使用MYSQL，只是應用開發上設定一些開發規范，避免比較復雜的多表查詢語句。因為他們銷售的是套裝軟件，總體的研發成本會被大量的用戶攤銷，因此提高軟件質量本身就是日常工作的重點。而他們的客戶在運維方面的能力較弱，每個項目的經費也有限，較難提供比較豐富的支撐服務。使用MYSQL可以大幅度降低運維的復雜性，只要教會客戶在系統有問題的時候殺死慢查詢的會話，或者直接殺掉數據庫進程，自動重啟應用就可以解決大部分問題了。如果換成PG數據庫，在運維方面將面臨更大的復雜度，其成本遠遠高于在應用上加以優化。

實際上，PG數據庫和MYSQL數據庫從底層設計思想上是完全不同的，MYSQL數據庫自從誕生以來就是一個簡單易用的關系型數據庫，用于一些數據規模不是很大，業務復雜度不是很復雜的廠家。隨著這些年的發展，MYSQL已經發展出了10多種存儲引擎，通過不同的存儲引擎可以實現各種各樣的業務場景。MYSQL本身就是一個和應用與應用開發結合的很緊密的數據庫，受到開發人員的喜愛也并不意外。

而PG數據庫是一個對象關系型數據庫，是一款真正的從核心就是對象數據庫的數據庫產品。是比Oracle這種號稱對象數據庫，實際上只是在關系型數據庫中加入了一些對象支持的數據庫產品還正宗的對象數據庫。正是因為如此，PG數據庫略微復雜一些，支持更多的業務種類與開發模式。因此在各種功能支持上，PG數據庫比MYSQL更為豐富一些，把Oracle上開發的應用系統遷移到PG上也更容易一些。不過因為PG數據庫的復雜性，也導致了PG數據庫的運維和調優也更為復雜一些。

雖然說二者的出廠默認參數設置的都不太合理，不過如果二者都用默認參數運行，PG數據庫可能會跑的更流暢一些，因此有些人以此為依據進行測試對比，得到了PG數據庫性能碾壓MYSQL的結論，實際上這種比較是極不科學的。如果都是經過了充分調優，二者在相同的硬件配置下做TPMC壓測，性能也是比較接近的。

回到選擇數據庫產品本身來說，我們可以根據自己的應用場景，研發團隊的特點，運維團隊的能力，企業以往的歷史積累來選擇項目所使用的數據庫。如果你的開發人員能夠寫出質量比較好的SQL，那么選擇MYSQL可能會對以后的長期運行有利。如果你的業務確實特別復雜，而開發團隊的SQL又寫得特別爛，那么就別硬撐著用MYSQL了，選PG可能以后會省心一些。

2012年的時候，和騰訊的朋友交流，那時候騰訊在一般的交易類應用里用MYSQL數據庫，而在數據集市中使用PG。我那時候還主要在搞Oracle，對MYSQL/PG的特點不太了解。我就問他們，為什么這么選擇，他們也說不出特別的道理，只是說他們公司的系統傳統上都是用MYSQL，只是數據集市中經常有比較復雜的SQL語句，經過對比發現MYSQL性能不如PG，于是他們就在這個領域全部選擇了PG。