5.7VS8.x,为什么用户不升级MySql

安全运维得看我 2024-06-22 09:26:07

一般来说为了更好的功能和性能,都需要将软件升级到最新的版本,然而在开源软件中,由于一些开发商变化或其他的问题(开源授权变化),致使人们不愿使用最新的版本,一个最典型的问题就是CentOS操作系统。还有一个案例就是广泛使用的MySql数据(PHP也是),基本还停留的5.x版本,现在Mysql 5.7已经EOL结束生命周期,但是还有大量的用户却还没有升级,为什么会这样呢?

概述

根据一个版本分布数据图(源自Percona)

还有大量的用户使用MySql5.7 上(小伙伴你用那个版本?)。

为啥EOL后用户还是愿意用老的版本不愿意升级到新版本?除了兼容性问题外,还有其他问题没有,针对这个问题Percona进行一些测试,来尝试发现一些端倪。

测试方法

运行测试的方法有很多种,结果可能会有所不同,具体取决于操作方式以及许多因素,例如环境或MySQL服务器设置。然而,如果比较同一平台上同一产品的多个版本,则可以合理地假设所有版本都有相同的“机会”表现良好或较差,除非我们更改MySQL服务器设置。高水平上,运行两组测试:

系统平台

TPC-C类似系统平台:

结果

通过执行整套测试,来看一下读写测试和TPC-C的部分内容。sysbench读/写测试的写入百分比较低,约为36%,读取百分比较低,约为64%,其中读取是点选择和范围选择。相反,TPC-C在读取和写入操作之间均匀分配 50/50%。

Sysbenc读写测试

不同版本仅使用MySQL默认配置进行测试。

小数据集:

仅优化MySQL配置:

使用默认值的大型数据集:

使用优化:

现在看看上面的图表,可以得到看到:

仅使用默认值,MySQL 5.7在这两种情况下都表现得更好。由于默认值不好,MySQL 8.036在第一种情况下表现不佳;进行一些调整后,8.0就可以超越8.4,并更接近5.7的性能。TPC-C测试

如前所述,TPC-C测试应该是写入密集型的,使用事务和更复杂的连接、分组和排序查询。

使用最常见的隔离模式、可重复读取和已提交读取来测试TPC-C。

多次运行期间遇到了几个问题,但这些问题并不一致,主要是由于锁定超时。鉴于此,虽然图表中用空白表示问题的存在,但它们不应被视为影响执行趋势,而仅代表饱和限制。

使用优化配置进行测试:

使用优化配置进行测试:

在此测试中,可以观察到MySQL 5.7与其他MySQL版本相比性能更好。

其他MySQL变本比较

通过加入Percona Server和MariaDB一起来对比测试,在优化参数情况下,对比小批量数据和大量数据两种情况,结果如下

当将MYSQL版本与Percona Server for MySQL 8.0.36和 MariaDB 11.3进行比较时,我们发现MySQL 8.4仅相对于MariaDB表现更好;与MySQL 8.0.36 相比仍然落后。

和预期一样,MySQL 8.4在TPC-c测试中也表现也不佳,MariaDB表现也同样更差。

总结

根据测试,我们可以明显得到结论MySQL的性能随着版本的增加而下降了。虽然MySQL 8.x带来了一些有意义的新增功能;但是,其性能并没有实质上提高。所以大多数仍在使用 MySQL 5.7 的人是正确的。为什么要进行一次非常危险的迁移,最后却发现性能下降了呢?

对此,如果分析数据并将趋势转换为事务数/秒,如果我们比较使用TPC所做的测试:

正如我们所看到的,在这两项测试中,性能下降可能都很严重,而好处(如果存在)则无关紧要。

以绝对数字表示:

从测试结果来,大家用户保持在5.7是有充分理由的,在能够解决这个问题之前,他们可能决定永远不再迁移。如果非要迁移话,还不如直接迁移到Postgres。

0 阅读:0

安全运维得看我

简介:感谢大家的关注