根据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 结论 不要相信基准指标。它们对你特定的工作负荷及纯粹的营销活动来说大多是没有意义的…，包括以上提到的！;-) 数据库供应商（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
