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

2015-07-06數位

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

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

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

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

對於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等大數據處理工具來分析；

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

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

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

豐富的數據型別 - 通常用處不大，常用型別足夠了。如果有復雜型別，業務上自己序列化，儲存成varchar就行。可以用json，PB，avro等。序列化反序列化都發生在業務伺服器，更好維護和最佳化；
強大的審計函式 - 互聯網早期活下來是一切，審計並不是核心需求（通常需要嚴格審計的領域早就會用Oracle/MSql，不差錢）；
強大的索引。postgres的自訂索引功能很強大。但是對於mysql，關鍵的幾列有索引就夠了，不需要復雜的高級索引。我承認早期mysql的查詢最佳化器智商堪憂，但如果要改，一句explain，然後force index也就是了。對於開發人員簡單直接。有一段時間LBS很流行，當時mongo很潮的直接支持了空間索引。當時大家紛紛的「NoSQL」，就更不會看postgres一眼。然後到了大概2015年，mysql 5.7也支持空間索引了。
Posgres的MVCC實作牛逼不，牛。serial snapshot isolation是很強。但是到了需要變更數據嚴格一致的時候，select ... for update又不是不能用：）
對於序列號，sequence是很好。但是互聯網公司對於簡單場景用auto increment。對於生產場景就直接用分布式序列號生成服務了。postgres的序列號產生器～偏雞肋。
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"的標語去折騰，更不會為了資料庫愛好者的情懷做傷害利益的事情。