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

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

查询语句如下:

1SELECT *

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）么？

1innodb_buffer_pool_size = 768M

2innodb_buffer_pool_instances = 1

3innodb_file_per_table = 1

结果

图表

结论

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

数据库供应商（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对于这个测试也提供了很多帮助。

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