吃葡萄不吐葡萄皮，不吃葡萄倒吐葡萄皮！这句话熟悉吗，今天咱们要说的是 “用MySQL不是MySQL,不用MySQL都是MySQL”，横批 MySQL要倒霉。估计聪明的人已经知道今天的主题是什么了，这个题目和问题也是我最近听了某数据库的开门会议，对就是那个色，加三个色标签的数据库，加上4群昨天的讨论，让我又有创意了，感谢4群的同学们。
这话的从哪里说起，这的从MySQL自身说起，用MySQL的量在业内还是比较大的，但是我们要注意，兼容MySQL的数据库也是一堆，且这些数据库大部分的数据处理能力都比 MySQL要强。
兼容MySQL数据库在业内是一个共识，也是能最快找到客户群的一种方法，这个方法最早是在TIDB上兴起的，最早Tidb发家就是从兼容MySQL开始的 遥想2016年，当时做数据库也都明白，做自己的操作方式只能是死路一条，而如果想让这个数据库活起来，必须兼容MySQL，好在MySQL简单，比Oracle ，MSSQL的功能要简单的多，所以兼容MySQL并不是难事。
后面兼容MySQL的数据库就太多了，比如我们现在用的PolarDB, 以及装机率最高的OceanBase，其他的国产数据库大多也都兼容MySQL,比如的太多，你抄起市面一个数据库大部分都兼容MySQL等。那么这些和MySQL倒霉,这个横批有什么关系。
关系大了，因为MySQL在数据处理能力上的短板，这一直是数据库业界（业内人士）并未高看MySQL的原因，这就如同屌丝，你数量再多，也是屌丝，其他数据库产品把自己装扮成屌丝，但只要你接近那些人，就发现不是带着劳力士，就是绿水鬼，脚上不是Regal,就是Loake。这就和这些数据库产品一众说我们兼容MySQL，但核心和使用价值以及数据的承载力，都甩MySQL几条街。
比如TIDB，OceanBase都是分布式，都具有大量的数据存储和处理节点，数据运算速度快，可以执行复杂的SQL，且数据容量承载的上限都是不是MySQL单体可以比拟的，或者PolarDB for MySQL,你说他用着和MySQL基本一样，但就是性能好，就是一会儿可以插入IMCI列式存储，一会可以快速增加只读节点，甚至多写节点，这些功能让MySQL单机非常的尴尬，这就如同一群30岁的博士穿越回幼儿园，然后他们穿着幼儿园校服，和MySQL这样的真儿童在一个桌上抢饭吃。
MySQL能有好，而更多的问题是MySQL的DBA们，看似这些数据库和MySQL在语句处理上，命令大部分规范都差不多，可底层的原理那是哪都不一样，这对DBA来说这就是新的数据库，都是需要新的学习和使用经验的，可不懂的人会说，不都兼容MySQL吗？不都差不多吗？为什么你们MySQL DBA，不会这些兼容MySQL的数据库呢？
更可怕的是，迁移，都兼容MySQL且比MySQL功能强，各种功能都组合在一起了，开发这时就不会成为应用迁出MySQL的挡路石，剩下的就是 MySQL DBA 在各种不会中，赶紧学习那些兼容MySQL数据库的开始奋斗新征程。
当然这些还不算什么，更多的是在不断应用迁出MySQL后，MySQL的使用者会越来越少，至少现在有些大厂一直在抛弃MySQL，用尽心机用其他的数据库产品替换MySQL，当然我们也不是什么大厂，但就我们这样的，MySQL在我们这已经在2年内基本消失了。
那么在这次更替中，受伤的有那些人，想想都明白，咱们就不伤口撒盐，都是聪明人。最倒霉的是技能单一的 MySQL DBA。以前MySQL的敌人一直认为是PostgreSQL，可过了这么些年，MySQL最大的敌人是他自己，因为太简单，功能缺失多，对他不满意的人多，语句操作限制多，任何数据库往MySQL迁移大多需要重整应用，而MySQL到其他数据库上至少单体，还能是单体，不用考虑分库分表的问题，等等，虽然MySQL也在快速发展，可人们的认知还停留在他MySQL 5.x的年代，就在昨天，群里有人给出2024年的最流行的MySQL高可用，是keepalive, 我能得出的结论就俩字，停滞。
这就如同做人，如果太简单太单纯，别人两眼就看明白你会什么了，剩下的就只有被随意替代，且浑身的毛病还不自知，算了别说了，太刺耳了。
除此以外，MySQL的另一个问题是国产化中，如果以MySQL作为雏形进行研发后，即使使用了自有的技术也避免不了，甲骨文可能得诉讼，或对国内数据库公司产品，在怀疑使用MySQL源代码后，导致的产品不能进行开源的一些担心以及...... 所以.... STOP STOP 知道的太多不利于健康。
在补一句，看完后此文后，可能有人说，那我就不学MySQL了， 我只能小声说，你在想想，在你的世界都是黑白的？