首页 > 数据库 > mysql

MySQL单查询性能比较的真相
时间：2014-06-03 07:59:26 点击: 来源：作者：

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

根据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%20Graph

结论

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

数据库供应商（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？）。