观察结果:
在MySQL5.6，Percona 5.5和MySQL5.7中的8个表中用同样的Roint-Select-TRX只读测试(用事务)(2013.5月的结果) 同时你也可以看到，在同样的16核-HT配置下我们离峰值25万/s的结果还很远。 MySQL5.6在trx_sys互斥访问中延长了链接时间，而且自从64个用户后每秒的请求数将减少。 Percona5.5能维持很长的时间的负载，每秒请求在512个用户时才开始减少 当MySQL5.7已经保持一段时间时，每秒请求依然没有减少(对于更多用户并发的情况你在这幅图里是看不到的)...
然而，很明显，如果用MySQL想要得到最大的潜在每秒查询速率，事务应当避免。
让我们来看一看这是2013年5月我们的每秒最大查询速率。
在同一点八张表进行测试，但是没有使用MySQL5.6的事物：
观察：
上面的测试是保持MySQL5.6始终执行在16核上，然后是16芯-HT,32核，32芯-HT. 正如你所看到的，最大的每秒查询速率比预期的还要大 -—— 在MySQL上是每秒27.5万 最大的结果已经达到16芯-HT. 然而在32核上的结果并没有16芯-HT上的好（由于竞争中断，在相同内核中，具有2CPU线程的配置能够更好的管理线程竞争——所以真正的并发性仍保存在16线程，而不是32核上）
而在MySQL5.7上做同样的测试却看起来大有不同，因为在5.7中lock_sys互斥链接的时间段已经很低了，同时trx_sys互斥相关代码也得到第一次变化的情形：
观察结果：
首先你可以看到5.7在同样的16核-HT配置下的性能已经比5.6的要好 之后，在32核配置下没有明显的增强！ 在32核-HT配置下达到了35万/秒的最大请求！ 从上面特殊(具有攻击性)只读负载测试的情况下可以容易看出我们在32核中得到的结果要比16的好，同时我们还没有启动超线程(在32核-HT)...牛吧！；-）
从另一方面来讲，仍然有改进的空间这点还是很清晰的。有关trx_sys的争用仍然在持续。我们没有充分的使用CPU的能力来做有用的工作（仍然有许多CPU周期用在锁的轮转）...不过现在的结果比以前好多了，并且比5.6好很多，因此没有理由继续挖掘来提高这方面的性能，我们主要集中在我们曾经花费了巨大的空间的读写负载的性能提高上。
