以下均為個人感覺,沒做過統計,就當個參考吧。
mysql和postgres的早期完全是兩個極端。mysql更像是個「基本上滿足關聯式資料庫語法的大號KV」,對關系型數據庫的高級功能支持的很不好。我入行時接觸的MySQL 5.1和MyISAM儲存引擎,不支持ACID,但有如下幾點在當時的互聯網公司看來是非常合適:
反過來再看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"的標語去折騰,更不會為了數據庫愛好者的情懷做傷害利益的事情。