根據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.oschina.net/translate/mysql-single-query-performance-the-truth