以下均为个人感觉,没做过统计,就当个参考吧。
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"的标语去折腾,更不会为了数据库爱好者的情怀做伤害利益的事情。