当前位置:Gxlcms > mysql > MySQL单查询性能比较的真相_MySQL

MySQL单查询性能比较的真相_MySQL

时间:2021-07-01 10:21:17 帮助过:39人阅读

MySQL查询

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

The answer

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

The test

  1. SELECT *
  2. FROM a
  3. JOIN b ON b.a_id = a.id
  4. WHERE a.id BETWEEN 10000 AND 15000
  5. ;

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

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

  1. innodb_buffer_pool_size = 768M
  2. innodb_buffer_pool_instances = 1
  3. 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将非常乐意为您提供各种问题的解答。

原文链接:http://www.fromdual.com/mysql-single-query-performance-the-truth

译文链接:http://www.oschina.net/translate/mysql-single-query-performance-the-truth

人气教程排行