MYSQL 会不会成为下一个过时的数据库？

估计写这个话题的时候，不少人应该觉得这个人是不是 mental disorder

，如果我找出2019年年终的某篇关于POSTGRESQL的文字，那时我应该也是一个“psychotic” .

不过按照真理都在少数人的手里这样一个定式的话，这个话题且看且等,可以在等1-2年后看，看看我是不是疯子。

数据库业界里没有人不知道MYSQL ，MYSQL 成为一个流行的词汇，或许你可能都不大懂ORACLE ，但MYSQL 你不懂好像是 out of fashion 。

实际上从目前看，这个话题一点也不过分，可能不少3 4 5线的城市的大企业还在使用ORACLE引以为傲，而超1线的城市的前端企业，可能在部分业务替换了MYSQL数据库，所以时代气息一定不会在地域统一呈现的，而是逐步传递的，这个概念应该和地域有很大的关系，就如同我们这边都开上了国产的汽车，并且价格不高，但古巴的人民，可能还开着上世纪7-80年代的美国货也高高兴兴的。

你不能阻挡别人的快乐是吧，但MYSQL会不会成为一个过时的数据库，这个问题 BELOW

1  MYSQL 由于本身的数据存储原理，一直改变不了单表数据存储容量小的这个问题，并且在达到一定量级后衰减的厉害。（查询性能和插入性能）

2 MYSQL 就算8.0算起，这也是一个和其他数据库引擎在数据库查询优化方面有硬伤的数据库，NEST LOOP， 不能多表JOIN ，增加索引，字段对于大表要用工具的事实。

3  MYSQL 的开源协议不能再次商业应用，以及ORACLE 是否在ORACLE 失手后， 对MYSQL 的开源协议进行修改，或者闭源问题的可能。

4  开源产品对MYSQL 的支持变弱，例如XTRABACKUP 在文档中的一句话（具体参见前几期关于备份的文字），以及ORALCE化的MYSQL在一些参数调节过度中，拉胯扯到蛋的行为，如密码插件问题，以及MYSQL 8.0 与 python API 的问题改动较大。当然还有INNODB CLUSTER 在8.019 上的巨大变化当然有些是好的。

5  分库分表给开发造成的困扰，给运维造成的困扰，试想一个大型系统用了MYSQL 分表的话，对于整体应用架构设计以及运维的要求都比其他的数据库要求要高的多，不是每个传统型单位都能得心应手这样的设计和运维活动。就更别提数据库后还需要进行汇聚,开发和运维统统要为这个事情竭尽心力,因为分表后,或者分库后,必然在数据汇聚方面作出相关的事情,否则怎么对一张表进行复杂的查询. 所以分表从某种角度上将,是整体开发技术的一种象征,但这个象征也不是白白拿到了,运维后期对于分表的系统的维护的难度也可想而知.

6   众多的可以替代MYSQL 的产品蜂拥涌现，TIDB ，POSTGRESQL ，当然还有一群国产数据库。哪个和MYSQL比，MYSQL 都会败下阵。

 曾经使用MYSQL的自豪感，比如开源自由免费等等这些符合自由的精神，现在越来越淡。不可否认MYSQL的确推动了互联网产业的发展，互联网和MYSQL互相成就，但现在和10年前不一样了，好用的数据库如雨后春笋一样，在不用掌握中间件知识，以及一些蹩脚的优化规则，使用其他数据库是可以好好的运转。 

10年前，MYSQL是开源数据库产业中的独树一帜，10年后已经淹没在众多花海中，ORDBMS , NEW SQL ,NO SQL , 混合型的数据库的涌现，好像MYSQL 变得随时可以被替换。

相关的产业也在改变，一些以数据库维护业务的公司也在转换观念，变化终究是生存之本，原有的市场格局的变化，必然导致新的数据库产品和服务的需求。

所以到底MYSQL 会不会逐渐被淘汰，这个还真是不好说，终究一个产品必然有自己的产品生命周期，有的长有的短。

借用产品生命周期的定义：产品生命周期（product life cycle），亦称“商品生命周期”。是指产品从准备进入市场开始到被淘汰退出市场为止的全部运动过程，是由需求与技术的生产周期所决定。是产品或商品在市场运动中的经济寿命，也即在市场流通过程中，由于消费者的需求变化以及影响市场的其他因素所造成的商品由盛转衰的周期。

那么目前MYSQL ，在经过了导入期，成长期，必然会进入成熟期，衰退期。

问一句 8.0 很长时间了，多少企业导入了8.0 ，估计这个问题问的很扎心。

好了此时此刻,准备好迎接鸡蛋西红柿了.