為何在國內MySQL成為主流，PG只能屈居二線？

最近，小編在知乎上看到這樣一個問題：

PostgreSQL也很強大，為何在中 國大陸MySQL成為主流，PostgreSQL屈居二線呢？

PostgreSQL能否替代MySQL？我感覺PostgreSQL非常強大，很多地方超過了MySQL。

舉幾個例子：

1.豐富的數據類，支持陣列、字典、json、序列號

2.強大的審計函式

3.強大的索引，易於sql調優

PostgreSQL在許多地方，有MySQL無法比擬的優勢。 但是在中國大陸，許多公司的核心業務庫，都是MySQL，PostgreSQL則屈居二線，作為審計類的資料庫來使用。

為什麽不讓PostgreSQL來扛大梁呢，而要用MySQL，PostgreSQL不合適麽？

MySQL和 PostgreSQL在功能上各有千秋，為什麽沒能在業界中形成「平分天下」的局面呢？ 小編精選了幾位知乎網友的精彩回答，分享給大家學習交流（仁者見仁，智者見智，勿引戰~） ：

1號知乎網友：大寬寬

以下均為個人感覺，沒做過統計，就當個參考吧。

MySQL和Postgres的早期完全是兩個極端。MySQL更像是個「基本上滿足關聯式資料庫語法的大號KV」，對關系型資料庫的高級功能支持得很不好。我入行時接觸的MySQL 5.1和MyISAM儲存引擎，不支持ACID，但有如下幾點在當時的互聯網公司看來是非常合適：

1. 互聯網公司為了擴充套件，長期的經驗是， 僅僅把資料庫當作是一個「儲存」 ，而非儲存+核心數據邏輯的計算節點。大量的計算都在業務伺服器上進行，而業務伺服器可以無限水平擴充套件，無需擔心有狀態的數據遷移問題；

2. 因為沒有提供很多高級功能和數據一致性的保障，MySQL對於簡單的sql支持的反而更加直接，在 速度上有很大的優勢 ；

3. 對於OLTP，完全不需要復雜的數據處理功能 。簡單的select ... from ... where id = xxx; insert into xxx；update xxx set xxx=xxx where id = xxxx是OLTP的主流功能。基於這些功能的ORM的出現大大提高了生產效率；對於OLAP，盡管Postgres查詢分析功能很強，但是一般互聯網公司的數據量實在太大，用Postgres這種資料庫根本無法處理。通常會用MapReduce、Hive、Pig等大數據處理工具來分析；

4. 多執行緒模型，天然對高並行支持良好 。而pg一直是多行程模型。行程的建立會更慢，更耗記憶體。雖然有些PG的連線池方案，但是MySQL在這方面「開箱即用」；

5. Postgres早期並不支持「邏輯復制」。 物理復制意味著儲存格式的細節完全暴露，不相容的版本無法直接組成主從同步，於是 無法做捲動升級 。這就意味著在升級資料庫時，必須停服，把整個集群升級後再恢復。而MySQL從一開始就是邏輯復制（這其實是由於MySQL一直是server和儲存引擎分層的架構，邏輯復制發生在server層）。這個缺陷會讓Postgres的營運不受業務開發者的待見。誰也不希望自己的業務停服。

反過來再看Postgres的優點，會發現對於OLTP並沒有太大的吸重力：

1. 豐富的數據型別： 通常用處不大，常用型別足夠了。如果有復雜型別，業務上自己序列化，儲存成varchar就行。可以用json，PB，avro等。序列化反序列化都發生在業務伺服器，更好維護和最佳化；

2. 強大的審計函式： 互聯網早期活下來是一切，審計並不是核心需求（通常需要嚴格審計的領域早就會用Oracle/msSQL，不差錢）；

3. 強大的索引： Postgres的自訂索引功能很強大。但是對於MySQL，關鍵的幾列有索引就夠了，不需要復雜的高級索引。我承認早期MySQL的查詢最佳化器智商堪憂，但如果要改，一句explain，然後force index也就是了，對於開發人員簡單直接。有一段時間LBS很流行，當時MongoDB很潮地直接支持了空間索引。當時大家紛紛「NoSQL」，就更不會看Postgres一眼。然後到了大概2015年，MySQL 5.7也支持空間索引了。

4. Posgres的MVCC實作 牛不？牛。serial snapshot isolation是很強，但是到了需要變更數據嚴格一致的時候，select ... for update又不是不能用：）

5. 對於序列號，sequence是很好。 但是互聯網公司對於簡單場景用auto increment，對於生產場景就直接用分布式序列號生成服務了。Postgres的序列號產生器～偏雞肋。

6. Postgres的全文索引很強 ，但強得過ES？強得過專門客製的搜尋引擎系統？要知道搜尋業務最關鍵的是把「最匹配搜尋人需要的搜尋結果返回出來」，而不是僅僅「能搜到一堆不分主次但滿足關鍵字匹配的結果」。

因此早期MySQL變成了事實上的互聯網企業OLTP的事實標準。不管幹啥業務，MySQL都不可或缺。在行業裏跳槽來跳槽去的程式設計師普遍對MySQL也更熟悉。大量圍繞MySQL的商業服務都成為了行業主流。新一代分布式資料庫，像TiDB為了吸引使用者，首先要做的是「相容MySQL的語法」。

再往後，MySQL增加了更多「關系型資料庫該有的」功能，比如完全支持ACID的innodb成為預設儲存引擎，比如5.7的json原生支持，8.0的window function/CTE。而Postgres也增加了更多的「互聯網功能」，但是時機已經過去了。大家MySQL跑著業務好好的，而切換資料庫絕對不是僅僅像某些ORM標榜的換一個Dialect就行的，整個編程模型，效能表現，運維工具和流程都要有巨大的變化。如非必要，犯不著為了一個「most advanced」的標語去折騰，更不會為了資料庫愛好者的情懷做傷害利益的事情。

2號知乎網友： 羅詩亞

我已經不寫程式碼、做技術管理一段時間了，但是有些支持工程師做技術選型的經驗，根據業務上的需求來聊一聊吧。這裏一半是我們技術選型時TL告訴我的，一半是我個人程式碼實踐的經驗。

資料庫這種早期用了就基本不能換的東西是有滯後性的，你看到 現在MySQL的現狀，是「5年前MySQL是國內幾乎唯一選擇」造成的情況 。5年前Postgres就已經在歐美初創計畫裏比較受歡迎了，國內公司數據量、體量是國外公司無法比的，畢竟使用者人數多，隨便都上億，而且國外這幾年新計畫活得好的公司都是B2B，有幾十萬上百萬使用者量就很不錯了。

Postgres 有scaling issue （擴充套件問題？這個詞中文怎麽說），一個表2-3T就不行了，不做大量最佳化查詢速度就以秒開始做單位了，這是雲資料庫提供商不會告訴你的。他們只會告訴你Postgres的優點。題外話，NoSQL也有類似的壞處。但是除非在生產環境中踩過坑，沒有人會告訴你的。在技術社群裏噴某個解決方案不行是會被鄙視的，特別是大公司，有這種體量業務的工程師是沒時間跟你說這種掃興的話的。

Postgres的好處之一是有好幾年給新語言的ORM比MySQL成熟，對全棧工程師更友好。歐美的全棧工程師一般是手稿語言後端（Node、RoR、Python）加上前端。國內更流行的是強型別語言（Java）後端，一般不會同時前端的，Java + MySQL是真香。歐美這種全棧工程師的弱點就是對後端沒有那麽深的理解，這裏就不細聊了。

前幾年不需要運維支持就能部署的雲服務提供商（Digital Ocean、Heroku）只支持Postgres。同上，全棧工程師一般是沒有運維能力的。EC2上給你裝個MySQL？RDS的文件能看懂就很不錯了好嗎~

MySQL對於你說的那些Postgres優點，都在國內有業界已經驗證過，實施經驗人數也很多的最佳解決方案。而且那些優點，是工程師做得爽而已，跟業務沒啥實質性的關系。而踩過Postgres坑的這種人招不到，才是阻礙業務的第一大要素。

最後，為什麽都是data類才用PG，因為data不是業務組，運維支持力度沒那麽大，也沒有即時效能上的壓力，上面的壞處不是什麽壞處，好處卻是可見的，能夠提高開發速度的。

寫得不對的請勿噴，哈哈。

3號知乎網友： 靈劍

這可能還真的跟PHP有點關系 ，PHP很早的版本就有內建的mysql支持，很多Linux發行版都可以一鍵安裝LAMP套件（Apache + MySQL + PHP），基本不用配置就可以開始用。其實國內PHP流行的時候已經有pgsql的支持了，但是習慣和早期沿襲的資料的影響仍然是巨大的。因為MySQL用得多，自然熟悉MySQL的DBA也多，熟悉pgsql的DBA少，也就進一步影響了其它語言的選型。

對於當時的大部份開發者和公司來說，PGSQL的那些高級功能反正也不會用，自然就跟不存在沒什麽兩樣。

4號知乎網友： 聿明leslie

說說鄙人的見解。

從技術而言，PG 功能豐富 ，SQL 支持得很完備，強大的數據型別，嚴謹的關系模型，很難從關系模型去找出PG的不合理之處，多年積累，連全文索引詞庫都非常豐富，據說對於一些簡單的搜尋，都可以擺脫搜尋引擎了，最佳化器做得很好，在代價選擇上 PG 實作了基因演算法，這一點連Oracle 也沒有做到。

讀過一部份 PG 的程式碼和 MySQL 的程式碼，對比起來，PG 的程式碼寫得非常工整，註釋也很細致，真的可以稱得上code 教科書級別的工程，一定是一幫有情懷的coder 寫出來的，對比起來，MySQL 就是一坨……

可是 這個問題是一個工程性問題 ，就不要用這些方面來衡量一個工程問題！

歷史總是時勢造英雄，看看MySQL 火起來的那段時間，正是互聯網爆發式增長的那幾年。 由於PG 豐富的功能，所以它顯得太重了，多行程並行，再加上早期的儲存做得不夠好，太吃資源。 在 那個時代，記憶體和儲存都是比較昂貴的資源，早期的PG 效能也不太好，由於關系模型支持得很好，用起來會有諸多限制，學習成本會比較高。

比起這些， MySQL 要輕量很多，到現在這也是它的一個優點，在互聯網這個特定的場景中，大家為了追求快速叠代和拓展性 ，使用的 SQL 功能不會太多，都夠用。

而PG 由於更嚴謹的 SQL 關系模型，很多用法都限制得比較死，MySQL 卻要靈活很多，你的劣勢就出來了。 這個讓使用者用起來很爽，但是對於相容 MySQL 的相容實作者很痛苦；有些 feature 在特定的場景中用起很便利，但是在通用的模型中卻禁不起推敲，要不要相容它呢？ 但 使用者很難感知 到這些，除非測試去亂試，一般人不會那麽無聊，這就是工程上的權衡。 很難說誰好誰壞。

而用的人多了，相關的使用經驗會匯總到社群，形成部署方案、工具等，這又是工程中的正反饋。

在江湖中，有幾個身負各項絕技的大俠最後成了將軍和皇帝的？

5號知乎網友： flaneur

感覺是 在幾個互聯網痛點的時間視窗沒趕上 ，蠻可惜的。

之前 uber 有一篇文章：Why Uber Engineering Switched from Postgres to MySQL（ link.zhihu.com/?target=https://eng.uber.com/Postgres-to-MySQL-migration/ ）

裏面提到的幾個問題現在我猜應該有解決，但是時間點晚了，比如：

MySQL 給人的感覺就是「我啥都挫，要啥特 性沒啥特性，事務都用起來沒多少年，但是我十、二十年前就有主從邏輯復制跟 MHA」。

"為何MySQL在大陸成為主流，PostgreSQL屈居二線呢？" 歡迎在留言區交流，留下你的觀點 ~

整理丨dbaplus社群

來源丨知乎：zhihu.com/question/31955622

*僅為提供參考和學習交流，不代表dbaplus社群立場！ dbaplus社群歡迎廣大技術人員投稿，投稿信箱：[email protected]