一般来说为了更好的功能和性能，都需要将软件升级到最新的版本，然而在开源软件中，由于一些开发商变化或其他的问题（开源授权变化），致使人们不愿使用最新的版本，一个最典型的问题就是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%。

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

小数据集：

仅优化MySQL配置：

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

使用优化：

现在看看上面的图表，可以得到看到：

仅使用默认值，MySQL 5.7在这两种情况下都表现得更好。

由于默认值不好，MySQL 8.036在第一种情况下表现不佳；进行一些调整后，8.0就可以超越8.4，并更接近5.7的性能。

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

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

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

使用优化配置进行测试：

使用优化配置进行测试：

在此测试中，可以观察到MySQL 5.7与其他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。