MYSQL 忍不了, MYSQL 8 你脑子锈透了吧?

MYSQL 版本的一直在更新迭代,这是一个好事情,新的功能对老的问题进行修改补丁,但这需要一个过程,一个产品的核心是用户, 众多MYSQL 的用户到目前为止有几个进入到了MYSQL 8（我是进了踩了无数的坑,包括各种与开发的PK）, 这里的说说MYSQL 8 的N 宗罪.

数据库也是一个产品,并且数据库是一个综合性,服务面广的产品, 所以迭代的问题是需要考虑的, 当然这也是一个矛盾, 步子太大会"扯蛋". 下面就的说说MYSQL 8 到底怎么扯蛋了.

1 众所周知,MYSQL 5.7 依靠的是周边的"辅助"支持, 例如PT 工具 , GH-OST ,以及 xtrabackup 等等多种多样的工具的支持. 而MYSQL 8 上来就修改了用户密码的认证服务, 造成众多的第三方的软件无法使用, 所以MYSQL 8 在使用中必须在配置文件将默认的密码验证的方式改变成原来MYSQL 5.7 的方式.

一个产品你可以支持新的方式,但可以作为选配,而不是上来就直接更改. 这点用户的感受非常不好.

2 mysql shell 的引入, 这个功能实际上对于INNODB CLUSTER 的推广和安装部署的确是有帮助, 但这个功能的设计忘记了一个重点,就是学习成本, 大部分的DBA 人员都是使用一些MYSQL 周边的命令, 突然上了一套 MYSQL SHELL , 并且里面还支持三种模式, 这难道是走ORACLE EM的老路, 有几个ORACLE DBA 使用ORACLE 自家的 EM, 老老实实的做几个INNODB CLUSTER 的安装命令不好吗. 想想那推广的速度应该是比现在好.

3 INNDOB CLUSTER , 最早叫MGR , 这个功能在复制领域只能说鸡肋, 大厂们要从传统的复制变换为 INNODB CLUSTER 估计是难了, 小厂是可以使用,但是INNODB CLUSTER 对于软硬件,网络的要求那是很高的,也就是说如果你打算上 INNODB CLUTER 那么你要付出的硬件的成本就会提高. 尤其要确认事务复制的一致性(同步复制,非异步), 对于网络的稳定性以及硬件的响应和承载力都需要提高. 这无形中增加了成本, 所以要把现在的异步方式, 转换成INNODB CLUSTER (同步复制) 方式估计没有什么单位有这样的意愿.

4 产品核心的问题无法解决, 最值得吐槽的就是B+TREE 的数据存储方式, 根本的不改变, 那么单表数据承载能力的问题,那就会一直被吐槽到永远. 但如果数据的存储方式改变,则MYSQL 产品本身就如同打断腿,在重新接骨一样,不可想象. 所以根本的问题没有解决, 尤其在大型企业数据库选型来说, 后期的维护成本太高, 不如就直接上分布式的数据库, 反正最后MYSQL 还的分库分表,中间件, 不如就直接越级,一个数据库的选择对于企业的应用开发和后期的使用是很重要的. 所以这就面临一个问题,新的应用选型是 MYSQL ,还是PG 还是分布式数据库, 单从数据库的角度来看 MYSQL 是怎么都不占有优势.

5 版本变动频繁, 从下图可以看出MYSQL 8 的版本的变动的情况, 这样的变更的速度,让使用者无所适从, 刚确认好一个版本后, 就发现几个月后又有新的版本, 并且这个变动有些还是核心功能的变动,并不是BUG的FIX ,这就让人有些...... 所以有些企业使用MYSQL 8 等了又等, 不知道哪个好,应该用那个. 这说明两个问题, 1 MYSQL 8 迭代的速度快 2 MYSQL 本身的规划有问题,未考虑用户的在使用中和版本选择问题, MYSQL 你的版本迭代能在"快"一点吗?

,

6 一大批支持MYSQL 的软件在MYSQL 8 上失灵了, 例如gh-ost 目前我们使用的8.011 使用gh-ost 就出现了问题,无法正常使用.

包括一些商用的备份软件在MYSQL 8 上都失灵了, 具体是哪家就不说了,反正到目前为止这个商用的备份软件仅仅能备份,无法正常恢复MYSQL 8 数据库.

这就属于MYSQL 8 这个身体走的快, 但MYSQL 的周边支持类的软件灵魂还没跟上, 一般的企业盲目升级MYSQL 8 ,就如同在暗礁丛生的海里前行,不遇到问题,不触礁那是不大可能.

7 软件开发没有跟上, 之前开发人员在使用MYSQL 5.7 时基本上没有什么问题,但在升级到MYSQL 8 后, 各种问题就来了, 如 GROUP BY 与查询在MYSQL上升级为 FULL ,而大部分开发尤其是第三方的开发,还停留在MYSQL 5.7 , 要DB 修改 SQL MODE 参数,好适应软件开发中关于GROUP BY 的兼容性问题. 同时还有各种JAVA 框架与MYSQL 8 的各种 "恩恩怨怨".

总结, MYSQL 8 的数据库能力一直在提升, 但根本问题不解决,就如同隔靴搔痒,另外升级的零碎多了,让人无法侍从那个版本应该被选择, 周边的辅助性的软件跟不上, 学习成本又过高, 以及从MYSQL 5.7 升级到 MYSQL 8 的需求不明显,根本问题不解决, 不还是要分库分表,我升级你做什么. 还是老老实实用半同步异步复制, 等着MYSQL 8 周边成熟,以及任性的疯狂版本升级停下来再说吧.