建站
咨詢
售后
建站咨詢
新聞中心
根據(jù)morgo的建議suggested by morgo我對(duì) Impact of column types on MySQL JOIN performance一文中提到的查詢及數(shù)據(jù)集做了一些小測(cè)試，但是卻發(fā)現(xiàn)另一個(gè)層面的問題：響應(yīng)時(shí)間 (aka MySQL versions).
創(chuàng)新互聯(lián)建站致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營(yíng)銷，包括網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)、SEO優(yōu)化、網(wǎng)絡(luò)推廣、整站優(yōu)化營(yíng)銷策劃推廣、電子商務(wù)、移動(dòng)互聯(lián)網(wǎng)營(yíng)銷等。創(chuàng)新互聯(lián)建站為不同類型的客戶提供良好的互聯(lián)網(wǎng)應(yīng)用定制及解決方案，創(chuàng)新互聯(lián)建站核心團(tuán)隊(duì)10多年專注互聯(lián)網(wǎng)開發(fā)，積累了豐富的網(wǎng)站經(jīng)驗(yàn)，為廣大企業(yè)客戶提供一站式企業(yè)網(wǎng)站建設(shè)服務(wù)，在網(wǎng)站建設(shè)行業(yè)內(nèi)樹立了良好口碑。
The answer
簡(jiǎn)單的說(shuō)。作為名優(yōu)秀的咨詢師，這些結(jié)論都是有前提的 ????
The test
- SELECT *
- FROM a
- JOIN b ON b.a_id = a.id
- WHERE a.id BETWEEN 10000 AND 15000
- ;
以下所有測(cè)試都基于相同的查詢語(yǔ)句
MySQL相關(guān)的參數(shù)設(shè)置如下。我還需要考慮 join buffer或是其他的單會(huì)話的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
結(jié)論
不要相信基準(zhǔn)指標(biāo)。它們對(duì)你特定的工作負(fù)荷及純粹的營(yíng)銷活動(dòng)來(lái)說(shuō)大多是沒有意義的…，包括以上提到的！;-)
數(shù)據(jù)庫(kù)供應(yīng)商（Oracle、MySQL，Percona，MariaDB）主要關(guān)注吞吐量和特性。基本上基準(zhǔn)指標(biāo)表述的都是單次查詢的性能成本。
Facebook、LinkedIn、Google、Wikpedia、Booking.com、Yahoo!等MySQL用戶相比單次查詢的性能對(duì)吞吐量更感興趣（我是這么認(rèn)為的）。但大多數(shù)的MySQL用戶（95%）不會(huì)有吞吐量的問題，但會(huì)有查詢性能問題（在這我假定對(duì)Oracle，DB2，MS-SQL Server，PostgreSQL等也是這樣）。
所以數(shù)據(jù)庫(kù)供應(yīng)商的產(chǎn)品主要不是服務(wù)于大眾，而是為某些特定的用戶/客戶（他們才可能為之付錢）。
讓我回到關(guān)于數(shù)據(jù)的討論：
第一個(gè)假設(shè)：“過(guò)去的時(shí)光總是更好”是絕對(duì)不正確的。 MySQL的4.0和4.1只是個(gè)特例?；贛ySQL5.0粗略估計(jì)的趨勢(shì)是：隨著時(shí)間的推移（新版本）單一的查詢性能會(huì)變得更差。我想這也適用于其他數(shù)據(jù)庫(kù)...
像一些聲稱：“我們擁有最快的MySQL”或“我們已經(jīng)聘請(qǐng)了整個(gè)優(yōu)化團(tuán)隊(duì)”并不需要反映在單一查詢的性能上。至少不會(huì)為了某一個(gè)特定的查詢。
因此，概要的說(shuō)：如果您升級(jí)（MySQL的< - > Percona的< - > MariaDB的），則需要很小心的測(cè)試！其中陷阱是不可預(yù)測(cè)的。較新的MySQL版本或許可以增加你的應(yīng)用程序的性能。孩子，不要太相信市場(chǎng)。
一些假象
我們這個(gè)小小的測(cè)試過(guò)程中已經(jīng)發(fā)現(xiàn)了一些假象：
在MySQL 5.0中引入的優(yōu)化（不是在優(yōu)化?。浚。蟠蠹涌靻我惶囟ǖ牟樵?。
MariaDB的5.2和5.3在這個(gè)特定的查詢表現(xiàn)很糟糕。
我不知道為什么Galera集群已經(jīng)顯示出5.5是最好的那個(gè)版本。這不是故意的或操縱的！這結(jié)果真是運(yùn)氣不佳。但我喜歡它！ ????
MySQL的5.6在這些查詢上似乎有一些問題?？赡苡蒓racle給MySQL帶來(lái)了太多的改善的原因？(╯‵□′)╯︵┻━┻
Percona版本的5.6這些查詢上比普通的MySQL有時(shí)會(huì)表現(xiàn)更好，但有時(shí)候什么Oracle優(yōu)化使得Percona的速度大幅放緩。因此，顯示出 特別壞的結(jié)果。我不知道為什么。我第一反應(yīng)是外部的影響。但我有能力重現(xiàn)這種糟搞情況（一次）。所以我認(rèn)為這一定有什么在Percona的內(nèi)部（例如 AHI？）。
最后
兩國(guó)交戰(zhàn)不斬來(lái)使！
如果您不滿意這里已經(jīng)發(fā)布的計(jì)算結(jié)果想重新計(jì)算?；蛘哌@里遺漏了什么，煩請(qǐng)告知本人。
如果您對(duì)這個(gè)結(jié)論不認(rèn)同也請(qǐng)告訴我。我也好溫故而知新
今天的這個(gè)測(cè)試很有趣。我的MyEnv對(duì)于這個(gè)測(cè)試也提供了很多幫助。
如果您需要我們?yōu)槟鲞@個(gè)測(cè)試，請(qǐng)聯(lián)系我們。我們的咨詢團(tuán)隊(duì)consulting將非常樂意為您提供各種問題的解答。
網(wǎng)頁(yè)題目：MySQL單查詢性能比較的真相
瀏覽路徑：http://www.dlmjj.cn/article/ccdspid.html
