紧随《MySQL学习分享 --机型选择和配置》，虽然没有什么太多的反应和关注，但前进的步伐没有停止。小插曲：电脑被儿子摔坏了，突然感觉失去了方向。忍不住到网吧来看技术文章，似乎有些格格不入，粗鲁嘈杂的声音，并没有影响我的专注和文章质量。
3、《 MySQL Performance: The Road to 500K QPS with MySQL 5.7 》
MySQL 5.7 的性能达到另外 50WQPS，看到这样的标题，我惊呆了。虽然是一遍测试文章，细细读来，还是有许多知识可以挖掘。
文中指出， MySQL 5.6在RO只读系统下，有很大的提高，而5.7不仅在RO只读系统中，提升较大，对RW读写场景，也有较大的性能提升。 Innodb性能影响主要有MDL、 trx_sys和lock_sys 三个，其中 MDL在单表查询时，是主要的瓶颈，单表查询需要对元数据加锁保护，这个毋庸置疑；多表查询时，每个表有 MDL进行保护，更大的瓶颈会落在 trx_sys和lock_sys 上。一个重要的信息是：当 CPU从16 HT 到32时，性能反而下降。从以上思路可知，更多的线程处理，反而造成锁冲突和等待。
MySQL 5.7 改进一：自动检测只读事务。对于只读事务来说，如果可以自动检测出来，可以减少 MDL锁开销。同时，文中也提到， percona团队通过改进trx_list锁的方式，提高只读事务的性能。从测试结果可知， MySQL 5.7的自动检测事务的方式，大大地降低了trx_sys锁和lock_sys锁，性能也有明显提升。而 Percona 5.5的优化方案在线程连接数较大时，锁竞争明显，性能也有所下降。此外，在接下来的测试中，发现随着CPU core的增加，性能明显升高，trx_sys锁也明显减少。
MySQL 5.7改进二：基于5.6版本，重写了trx_sys相关的代码。基于RW读写场景下，对RO场景性能影响的动机，重写trx_sys代码，降低事务锁的竞争。从测试场景看，随着CPU core的增加，QPS性能不断增长，最终使得CPU成为性能的瓶颈。
在CPU成为瓶颈的条件下，通过努力降低sysbench等工具的CPU资源，继续提高MySQL的性能，最终达到了50W的QPS。
个人观点：尽管测试场景简单，测试条件单一（Point-Selects），实际应用场景远远复杂的多，但是从MySQL 5.7表现出来的性能来看，非常值得期待。并且MySQL 5.7对trx_sys的重写，对RW读写场景也有较大的性能优化，但是仍然需要严格详细的测试。此外，在Innodb年会淘宝交流日中，与Innodb团队交流时，Sunny也表示，MySQL 5.7的改进和优化较大。总之，希望MySQL 5.7不要想5.6那样，让大家一直观望，而是不断推动用户使用。
参考资料
1、《MySQL Performance:The Road to 500K QPS with MySQL 5.7》：http://dimitrik.free.fr/blog/archives/2013/10/mysql-performance-the-road-to-500k-qps-with-mysql-57.html