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
