不存在的。怎么可能？
有人这样质疑过，而且我在实际环境中也被人质疑过。其实我们想想任何一个产品如果升级导致性能变差这都不会被认可。我相信任何软件尤其是数据库这种核心软件发布之前都是经过大量的测试，不会出现这种问题的。
过去我经历了一次质疑，十几个MySQL从5.7升级到8，我们主要目的是解决大表加字段停机的问题。因为MySQL8是加字段到数据字典中去，解决了这个问题。很多开发团队在升级过程中获得了收益。但是事情没那么顺利，有一次反馈说个别场景下大量单条提交变慢了。升级之前执行N万次大约累计用时100秒，升级后同样的操作累计用时300秒左右。场景大致为update t set xx where id=n。其中id是主键。这是一个普通的再普通不过的SQL。如果说这样的都慢，我感觉那基本我们也没法用了。我们先不谈为什么大量单条一次次提交而不是批量提交。主要是同样的操作为什么会慢了3倍。
我先把数据导出一份到了一个闲置的机器上，写了一个存储过程。
首先在MySQL8上执行。
循环将近10万次。红色是一条条提交，绿色是批量提交效果。 每条单次提交的写入为每次2.3毫秒左右。
接下来在5.7上执行。
循环将近10万次。红色是一条条提交，绿色是批量提交效果。 每条单次提交的写入为每次1.4毫秒左右
结论是：
MySQL5.7单条主键更新平均1.4毫秒。
MySQL8.0单条主键更新平均2.3毫秒。
单条更新每次大约慢了30%。虽然没有达到反馈的3倍的情况。但是这个结果很是打击我。 我开始质疑我自己，因为我相信官方做出来的不会是这样的，如果有问题一定是我的问题。这个观点从我开始工作我就一直保持，有问题先找自己的。无论是操作系统、应用软件还是数据库，只要是通用的知名的都是经过全世界检验的，有问题一定是我使用不当。
这个时候我把我的想法联系官方，官方也说不至于这样。让我再看看。各路大神们也有出谋划策的，有人建议我去跟踪一下。开启了跟踪以后我对比发现。
最下面出现的times就是14和23（也就是1.4毫秒和2.3毫秒），左边是5.7，右边是8。我们可以发现最大区别是8里面多了ioctl多了几次。查阅了一下资料，可能关系不大。因为下面这个蓝色显示8还快一点。
那一定还是什么环节上的问题。我又看了其他MySQL8上都是多了几个IOCTL的。我想这应该是MySQL和OS交互的动作，DB本来就是要频繁和OS交互的。
于是检查操作系统：
5.7的操作系统是：CentOS 7.6.1810 CPU 16C 内存 32G。
8的操作系统是：CentOS 7.4.1708 CPU 16C 内存 32G。可以看年初操作系统版本不一样。
本着严谨的态度。我决定用两个一模一样的再试试。
经过同事提供的克隆机器。两台机器仅仅数据库不一样。同一个宿主机的两个虚拟机，确保都是一样的环境。
步骤和上面的一样，经过10万次的单条Update压力测试，
MySQL5.7单条主键更新平均1.32毫秒。操作系统Red Hat 4.8.5-39 CPU 16C 内存32G
MySQL8.0单条主键更新平均1.40毫秒。操作系统Red Hat 4.8.5-39 CPU 16C 内存32G
结论：MySQL8和MySQL5.7在单条主键更新的场景下几乎无差别。（平均慢0.08毫秒我觉得这个可以视为无差别）之前30%的慢是因为操作系统版本有差异，现在几乎一致是因为两个操作系统都是一致的。至于为什么会反馈有的时候会慢3倍，我觉得主要是因为数据库整体运行状态。如果数据库处于亚健康的会产生的问题会是连锁的。而CPU超过50%的时候数据库就是亚健康状态的。我之前的模拟都是两个静态数据库的前提条件下，正式环境如果SQL质量过关大部分数据库应该是近似空载状态，那么是可以接近于我这个压测的状态。（压测为虚拟机本地磁盘，生产环境数据库必须是SSD）。所以归根结蒂，还是要提高SQL质量，让数据库处于健康状态才能有更好的并发。
