论坛 产品库 视频 专题 CIO俱乐部 Windows8 实验室 CMO俱乐部 案例

MySQL单查询性能比较的真相

发布时间:2014-12-16 15:48:00 来源:论坛 作者:译名
关键字:mySQL

  根据morgo的建议suggested by morgo我对 Impact of column types on MySQL JOIN performance一文中提到的查询及数据集做了一些小测试,但是却发现另一个层面的问题:响应时间 (aka MySQL versions).

  The answer

  简单的说。作为名优秀的咨询师,这些结论都是有前提的 :-)

  The test

  SELECT * FROM a JOIN b ON b.a_id = a.id WHERE a.id BETWEEN 10000 AND 15000 ;

  以下所有测试都基于相同的查询语句

  MySQL相关的参数设置如下。我还需要考虑 join buffer或是其他的单会话的buffers (read_buffer_size,read_rnd_buffer_size,join_buffer_size)么?

  innodb_buffer_pool_size = 768M innodb_buffer_pool_instances = 1 innodb_file_per_table = 1

  The results

  The Graph

the_truth.png

  结论

  不要相信基准指标。它们对你特定的工作负荷及纯粹的营销活动来说大多是没有意义的…,包括以上提到的!;-)

  数据库供应商(Oracle、MySQL,Percona,MariaDB)主要关注吞吐量和特性。基本上基准指标表述的都是单次查询的性能成本。

  Facebook、LinkedIn、Google、Wikpedia、Booking.com、Yahoo!等MySQL用户相比单次查询的性能对吞吐量更感兴趣(我是这么认为的)。但大多数的MySQL用户(95%)不会有吞吐量的问题,但会有查询性能问题(在这我假定对Oracle,DB2,MS-SQL Server,PostgreSQL等也是这样)。

  所以数据库供应商的产品主要不是服务于大众,而是为某些特定的用户/客户(他们才可能为之付钱)。

  让我回到关于数据的讨论:

  第一个假设:“过去的时光总是更好”是绝对不正确的。 MySQL的4.0和4.1只是个特例。基于MySQL5.0粗略估计的趋势是:随着时间的推移(新版本)单一的查询性能会变得更差。我想这也适用于其他数据库...

  像一些声称:“我们拥有最快的MySQL”或“我们已经聘请了整个优化团队”并不需要反映在单一查询的性能上。至少不会为了某一个特定的查询。

  因此,概要的说:如果您升级(MySQL的< - > Percona的< - > MariaDB的),则需要很小心的测试!其中陷阱是不可预测的。较新的MySQL版本或许可以增加你的应用程序的性能。孩子,不要太相信市场。

  一些假象

  我们这个小小的测试过程中已经发现了一些假象:

  在MySQL 5.0中引入的优化(不是在优化!?!),大大加快单一特定的查询。

  MariaDB的5.2和5.3在这个特定的查询表现很糟糕。

  我不知道为什么Galera集群已经显示出5.5是最好的那个版本。这不是故意的或操纵的!这结果真是运气不佳。但我喜欢它! :-)

  MySQL的5.6在这些查询上似乎有一些问题。可能由Oracle给MySQL带来了太多的改善的原因?(╯‵□′)╯︵┻━┻

  Percona版本的5.6这些查询上比普通的MySQL有时会表现更好,但有时候什么Oracle优化使得Percona的速度大幅放缓。因此,显示出 特别坏的结果。我不知道为什么。我第一反应是外部的影响。但我有能力重现这种糟搞情况(一次)。所以我认为这一定有什么在Percona的内部(例如 AHI?)。

  最后

  两国交战不斩来使!

  如果您不满意这里已经发布的计算结果想重新计算。或者这里遗漏了什么,烦请告知本人。

  如果您对这个结论不认同也请告诉我。我也好温故而知新

  今天的这个测试很有趣。我的MyEnv对于这个测试也提供了很多帮助。

  如果您需要我们为您做这个测试,请联系我们。我们的咨询团队consulting将非常乐意为您提供各种问题的解答。


比特微信账号
比特微信账号

微信扫一扫
关注Chinabyte

返回首页 长微博 返回顶部