PostgreSQL也很強大，為何在中國大陸MySQL成為主流，PostgreSQL屈居二線呢？
PostgreSQL能否替代MySQL？我感覺PostgreSQL非常強大，很多地方超過了MySQL。
舉幾個例子：
1.豐富的數據類，支持數組、字典、json、序列號
2.強大的審計函數
3.強大的索引，易于sql調優
PostgreSQL在許多地方，有MySQL無法比擬的優勢。但是在中國大陸，許多公司的核心業務庫，都是MySQL，PostgreSQL則屈居二線，作為審計類的數據庫來使用。
為什么不讓PostgreSQL來扛大梁呢，而要用MySQL，PostgreSQL不合適么？
MySQL和PostgreSQL在功能上各有千秋，為什么沒能在業界中形成“平分天下”的局面呢？小編精選了幾位知乎網友的精彩回答，分享給大家學習交流（仁者見仁，智者見智，勿引戰~）：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”的標語去折騰，更不會為了數據庫愛好者的情懷做傷害利益的事情。我已經不寫代碼、做技術管理一段時間了，但是有些支持工程師做技術選型的經驗，根據業務上的需求來聊一聊吧。這里一半是我們技術選型時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不是業務組，運維支持力度沒那么大，也沒有實時性能上的壓力，上面的壞處不是什么壞處，好處卻是可見的，能夠提高開發速度的。這可能還真的跟PHP有點關系，PHP很早的版本就有內置的mysql支持，很多Linux發行版都可以一鍵安裝LAMP套件（Apache + MySQL + PHP），基本不用配置就可以開始用。其實國內PHP流行的時候已經有pgsql的支持了，但是習慣和早期沿襲的資料的影響仍然是巨大的。因為MySQL用得多，自然熟悉MySQL的DBA也多，熟悉pgsql的DBA少，也就進一步影響了其它語言的選型。對于當時的大部分開發者和公司來說，PGSQL的那些高級功能反正也不會用，自然就跟不存在沒什么兩樣。從技術而言，PG 功能豐富，SQL 支持得很完備，強大的數據類型，嚴謹的關系模型，很難從關系模型去找出PG的不合理之處，多年積累，連全文索引詞庫都非常豐富，據說對于一些簡單的搜索，都可以擺脫搜索引擎了，優化器做得很好，在代價選擇上 PG 實現了基因算法，這一點連Oracle 也沒有做到。讀過一部分 PG 的代碼和 MySQL 的代碼，對比起來，PG 的代碼寫得非常工整，注釋也很細致，真的可以稱得上code 教科書級別的工程，一定是一幫有情懷的coder 寫出來的，對比起來，MySQL 就是一坨……可是這個問題是一個工程性問題，就不要用這些方面來衡量一個工程問題！歷史總是時勢造英雄，看看MySQL 火起來的那段時間，正是互聯網爆發式增長的那幾年。由于PG 豐富的功能，所以它顯得太重了，多進程并發，再加上早期的存儲做得不夠好，太吃資源。在那個時代，內存和存儲都是比較昂貴的資源，早期的PG 性能也不太好，由于關系模型支持得很好，用起來會有諸多限制，學習成本會比較高。比起這些，MySQL 要輕量很多，到現在這也是它的一個優點，在互聯網這個特定的場景中，大家為了追求快速迭代和拓展性，使用的 SQL 功能不會太多，都夠用。而PG 由于更嚴謹的 SQL 關系模型，很多用法都限制得比較死，MySQL 卻要靈活很多，你的劣勢就出來了。這個讓用戶用起來很爽，但是對于兼容 MySQL 的兼容實現者很痛苦；有些 feature 在特定的場景中用起很便利，但是在通用的模型中卻禁不起推敲，要不要兼容它呢？但用戶很難感知到這些，除非測試去亂試，一般人不會那么無聊，這就是工程上的權衡。很難說誰好誰壞。而用的人多了，相關的使用經驗會匯總到社區，形成部署方案、工具等，這又是工程中的正反饋。在江湖中，有幾個身負各項絕技的大俠最后成了將軍和皇帝的？感覺是在幾個互聯網痛點的時間窗口沒趕上，蠻可惜的。之前 uber 有一篇文章：Why Uber Engineering Switched from Postgres to MySQL（link.zhihu.com/?target=https%3A//eng.uber.com/Postgres-to-MySQL-migration/）里面提到的幾個問題現在我猜應該有解決，但是時間點晚了，比如：
MySQL 給人的感覺就是「我啥都挫，要啥特性沒啥特性，事務都用起來沒多少年，但是我十、二十年前就有主從邏輯復制跟 MHA」。
"為何MySQL在大陸成為主流，PostgreSQL屈居二線呢？"歡迎在留言區交流，留下你的觀點~
來源丨知乎：zhihu.com/question/31955622
該文章在 2024/3/15 15:17:44 編輯過
400 186 1886
