MySQL 英文原文：MySQL Performance: The Road to 500K QPS with MySQL 5.7

本文供给 MySql5.7完成每秒50W查询 一文的细节和基准测试后果，说明了我早期在Mysql Connect 宣布的说话。

回忆 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，trx_sys和lock_sys(InnoDB)
• 多表：trx_sys和lock_sys(首要是InnoDB)

任何很快的单表范畴测试的任务量首要因为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的后果，由于它的代码不地下)...所以，最少我如今可以做一些比拟：

察看后果:

• 在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好非常多，因而没有来由持续发掘来进步这方面的功能，我们首要集中在我们已经破费了宏大的空间的读写负载的功能进步上。

到了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核的超线程Server上到达了每秒可实行的查询440K!

5.7开辟里程碑宣布2长进行的Select 8个表所失掉的后果数：

不需求阐明..;-))

但是，有一个小小的使人奇异的地方－我们试图与Sunny经过分歧的Tools剖析一切瓶颈和代码更改所带来的影响。并且在某些测试里，令我受惊的是Sunny察看到比我更高的每秒可实行的查询数..这个“奇特的地方”与下面要素相干：

• 在高负载下，如今的５.7代码都运转在靠近硬件极限（首要是CPU)的地位，因而每条指令都十分主要！
• 假如运用的Unix套接字或许IP端口，那末辨别就会十分分明！
• Sysbench本身运用了30%的CPU工夫，不外异样的测试负载运用的是（具有更短的代码途径的）老版本的Sysbench的话，它将只运用20%CPU，残剩的10%用在MySQLServer上。
  
• 因而，异样测试负载的状况下，运用Unix套接字而不是IP 端口，而且运用Sysbench-0.4.8替换Sysbench-0.4.13的话，我们将失掉每秒可实行的查询数超越500K!-很轻易，不是吗？;-))
  

让我们来比拟“之前”和“以后”的差别

察看后果：

• 经过Sysbench下降了CPU的运用率。
• 在MySQLServer上具有更高的CPU可用性。
• 我们完成了50万每秒查询。

另有甚么呢？

我可能只提到：kudos Sunny和全部MySQL的开辟团队；

让我们看一下如今选择8张表任务负载的状况下的最大每秒查询。

• MySQL-5.7.2 (DMR2)
• MySQL-5.6.14
• MySQL-5.5.33
• Percona Server 5.6.13-rc60.5
• Percona Server 5.5.33-rel31.1
• MariaDB-10.0.4
• MariaDB-5.5.32

每一个引擎都在以下设置装备摆设下实行测试：

• CPU taskset: 8核-HT,16核，16核-HT,32核，32核-HT
• 并发会话数：8，16，32 ... 1024
• InnoDB自旋等候延时：6，96
  

最好的后果是来自恣意两个特定的组合间的比拟。经过对数据库引擎的比拟，我失掉了下面的一个图表，这个图表我在之前的文章中曾经提到过了。

下面是一些评论：

• 对Mysql5.7的宏大差距后果不需求做过量的评论，由于这是很分明的。
• 那末，风趣的是基于MySQL5.5的代码库引擎没有任何的靠近MySQL5.6的后果。
• 这曾经证明了在运用MySQL5.6的代码库引擎以后，Percona Server到达了MySQL5.6的程度，但是MariaDB-10依然还在探究的路上。
• 因而，毫无疑问，MySQL5.6是代码的基石!
• MySQL5.7是在MySQL5.6根底上的再一次优化扩大。

具有甚么样的扩大性呢？

谜底是容易的：MySQL5.7是独一在此根底长进行扩大的。

假如运用ip端口和一个分量级的Sysbench-0.4.13，会失掉以下的后果：

QPS只是略微的略低一点，可是整体的趋向是完整一样的。

可扩大性也长短常的类似：

更多的后果将会出来，敬请等待；

留意：对一个单表绑定过量的任务负载是欠好的：

• 减少InnoDB间的争辩使得其他的争辩愈加的分明。
• 当负载是绑定在一张单表上时分，MDL的争辩将变得愈加主导。
• 这是预期盼望的，我们鄙人一个DMRS大将坚持稳定。
  

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协定，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务