到了5月底，也就是我们的性能会议期间，Sunny给try_sys互斥争用增加了几个新的更改，从那以后最大的每秒可进行的查询（QPS）可达到375K！这是不是对5.7进行了足够的性能提高，对吗？;-)
同时，我们继续与建议用其他方式管理TRX列表的Percona团队交换了意见，他们的方案看起来非常有趣，不过在5.5上，这样的代码却不能展示出更高的每秒可进行的查询数（QPS），而且在5.6上的这样代码（曾经测试过Percona Server 5.6）最大的每秒可进行的查询数（QPS）也不会比在MySQL 5.6上大。然而，讨论涉及到一个有趣的观点：如果同时有一些读写负载在运行的话，它对只读性能有什么影响呢？...而且，即使在同样的测试条件下MySQL 5.7代码仍然运行的要好一些，效果是非常明显的（你可以在这儿查看我的分析，然而，再次说明一下，这段时间内我不能展示５.7上的结果，因为它的代码还没有对大众公布－也许会在以后的一篇文章中给出）..
由于这儿同时对任何纯粹的读写负载也有影响，因此有足够的动机以Sunnys很长时间所期待的那样重新写整个TRX列表相关的代码，然而，这种经历简直让人痴迷！
;-)) 日复一日，我们很高兴的看到我们的每秒可进行的查询图逐渐变高，直到在同一个32核的超线程服务器上达到了每秒可进行的查询440K!
5.7开发里程碑发布2上进行的Select 8个表所得到的结果数：
不需要说明..;-))
然而，有一个小小的令人奇怪的地方－我们试图与Sunny通过不同的工具分析所有瓶颈和代码更改所带来的影响。而且在某些测试里，令我吃惊的是Sunny观察到比我更高的每秒可进行的查询数..这个“奇异之处”与下面因素相关：
在高负载下，现在的５.7代码都运行在接近硬件极限（主要是CPU)的位置，因此每条指令都非常重要！ 如果使用的Unix套接字或者IP端口，那么区分就会非常明显！ Sysbench自身使用了30%的CPU时间，不过同样的测试负载使用的是（具有更短的代码路径的）老版本的Sysbench的话，它将只使用20%CPU，剩余的10%用在MySQL服务器上。 因此，同样测试负载的情况下，使用Unix套接字而不是IP 端口，并且使用Sysbench-0.4.8替代Sysbench-0.4.13的话，我们将得到每秒可进行的查询数超过500K!-很容易，不是吗？;-))让我们来比较“之前”和“之后”的差异
观察结果：
通过Sysbench降低了CPU的使用率。 在MySQL服务器上具有更高的CPU可用性。 我们实现了50万每秒查询。
