自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

MySQL單查詢性能比較的真相

開(kāi)發(fā) 前端 MySQL
根據(jù)morgo的建議suggested by morgo我對(duì) Impact of column types on MySQL JOIN performance一文中提到的查詢及數(shù)據(jù)集做了一些小測(cè)試,但是卻發(fā)現(xiàn)另一個(gè)層面的問(wèn)題:響應(yīng)時(shí)間 (aka MySQL versions).

根據(jù)morgo的建議suggested by morgo我對(duì) Impact of column types on MySQL JOIN performance一文中提到的查詢及數(shù)據(jù)集做了一些小測(cè)試,但是卻發(fā)現(xiàn)另一個(gè)層面的問(wèn)題:響應(yīng)時(shí)間 (aka MySQL versions). 

The answer

簡(jiǎn)單的說(shuō)。作為名優(yōu)秀的咨詢師,這些結(jié)論都是有前提的 :-)

The test

  1. SELECT * 
  2.   FROM a 
  3.   JOIN b ON b.a_id = a.id 
  4.  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)么?

  1. innodb_buffer_pool_size        = 768M 
  2. innodb_buffer_pool_instances   = 1 
  3. innodb_file_per_table          = 1 

The results

The Graph

the_truth.png

結(jié)論

不要相信基準(zhǔn)指標(biāo)。它們對(duì)你特定的工作負(fù)荷及純粹的營(yíng)銷(xiāo)活動(dòng)來(lái)說(shuō)大多是沒(méi)有意義的…,包括以上提到的!;-)

數(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ì)有吞吐量的問(wèn)題,但會(huì)有查詢性能問(wèn)題(在這我假定對(duì)Oracle,DB2,MS-SQL Server,PostgreSQL等也是這樣)。

所以數(shù)據(jù)庫(kù)供應(yīng)商的產(chǎn)品主要不是服務(wù)于大眾,而是為某些特定的用戶/客戶(他們才可能為之付錢(qián))。

讓我回到關(guān)于數(shù)據(jù)的討論:

第一個(gè)假設(shè):“過(guò)去的時(shí)光總是更好”是絕對(duì)不正確的。 MySQL的4.0和4.1只是個(gè)特例。基于MySQL5.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在這些查詢上似乎有一些問(wèn)題??赡苡蒓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將非常樂(lè)意為您提供各種問(wèn)題的解答。

原文鏈接:http://www.fromdual.com/mysql-single-query-performance-the-truth

譯文鏈接:http://www.oschina.net/translate/mysql-single-query-performance-the-truth

責(zé)任編輯:陳四芳 來(lái)源: 開(kāi)源中國(guó)編譯
相關(guān)推薦

2011-07-06 14:18:40

Percona SerMySQL

2011-04-28 09:49:56

SQLwith子查詢

2013-04-03 10:04:36

MySQL 5.6

2011-04-15 10:26:38

JavaMVC

2009-05-25 08:39:08

iPhone蘋(píng)果移動(dòng)OS

2012-12-03 10:26:51

Scala

2009-07-01 18:12:18

JSP的優(yōu)勢(shì)性能比較

2011-05-18 14:52:04

XML

2023-11-20 10:34:09

語(yǔ)言

2010-03-10 16:35:23

Python編程語(yǔ)言

2015-02-05 09:25:51

HTTPSSPDYHTTP2

2020-07-27 08:24:42

編程語(yǔ)言C語(yǔ)言Java

2009-12-16 14:10:12

路由技術(shù)性能比較

2015-03-09 10:40:44

MySQL大量數(shù)據(jù)插入

2009-12-04 19:28:25

FreeBSD 8.0Ubuntu 9.10性能比較

2010-12-27 16:01:45

jQuery選擇器

2023-11-19 21:17:58

GoRust

2014-08-20 09:49:50

虛擬機(jī)Linux Conta

2017-12-14 10:16:01

CaddySSLDockerNginx

2024-06-24 07:00:00

C++RustGo
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)