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