大幅优化MySQL查询性能的奇技淫巧

 回顾 MySQL / InnoDB 的改善历史。你能很容易发现。在MySQL 5.6稳定版本中从来没有在read-only 这么快的提速，它很容易搞懂，以及在read-only（RO）有着良好的扩张性。也很期待它在read+write（RW）上达到一个较高水平。（特别是在读取数据是数据库主要工作的时候）

然而。我们对于RO在 MySQL 5.6的表现也十分的高兴,在5.7这个版本中，主要工作集中在 read+write (RW)上, 因为在大数据的处理上还没能达到我们的期望。但是RW依赖RO下。能够再次提高速度。 InnoDB 团队通过不断的改进，强烈的推进优化着5.7这个版本的每秒的性能。

下面就按顺序为大家讲解

事实上，在MySQL中只读工作量控制内部链接的方式有以下两种：

任何很快的单表范围测试的工作量主要由于MDL链接导致锁住。而多表将会由于InnoDB内部构件限制(不同的表将由不同的MDL锁保护，所以这种情况下MDL中的链接瓶颈将会降低)。但是同样，也要看工作量的大小--一个比一般多的只读工作测量将会在MySQL5.6中表现的会更好(如Sysbench OLTP_RO),同时在工作量少而快的查询(如Sysbench Point-Selects(用外键去取一个记录))将会使所有链接变得困难，而且只能在16核-HT中测量，而在32核中表现很差..但是任何如Point-Select测试的工作量将在所有MySQL内部构件一起工作是会让你看到可能达到最大的性能(开始用SQL解析器，终止与取行值)..在你给定的MySQL版本和给定的HW配置下，这也可能达到最大SQL 查询/每秒(QPS)率。

在Mysql5.6上我们获得的最佳结果是25万个查询每秒，这也是那段时间Mysql/InnoDb上使用SQL语句查询得到的最好的结果了。

当然，只有在使用‘只读事务'功能才能达到这么高速度（Mysql5.6上的新功能）；另外，需要使用AUTOCOMMIT=1，否则CPU就会被轻易地浪费在启动事务、提交事务上，你会实际上损失系统的整体性能。

因此，在Mysql5.7上介绍的第一个改进是‘只读事务的自动发现'（实际上每个InnoDb事务都被认为是只读的直到有一个DML声明在此之外）功能---，这很大程度上简化了只读事务功能，节省了用户和开发者的时间，他们不用再去管理是否采用只读事务功能。但是，使用这个功能你仍然不能达到Mysql潜在的最佳每秒查询率，因为CPU时间还是浪费在事务的开启、结束状态处理过程当中。

同时，Percona用不同的的方案来解决“事务列表”管理(TRX-列表)及在InnoDB中trx_sys互斥链接慢的问题。Percona的解决方案在用事务处理Point-Selects高负载时能表现良好，但MySQL5.7表现一般(但我不会公布5.7的结果，因为它的代码不公开)...所以，至少我现在可以做一些比较：