成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

MySQL單查詢性能比較的真相

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

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

The answer

簡單的說。作為名優(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 

以下所有測試都基于相同的查詢語句

MySQL相關(guān)的參數(shù)設(shè)置如下。我還需要考慮 join buffer或是其他的單會話的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)。它們對你特定的工作負(fù)荷及純粹的營銷活動來說大多是沒有意義的…,包括以上提到的!;-)

數(shù)據(jù)庫供應(yīng)商(Oracle、MySQL,Percona,MariaDB)主要關(guān)注吞吐量和特性。基本上基準(zhǔn)指標(biāo)表述的都是單次查詢的性能成本。

Facebook、LinkedIn、Google、Wikpedia、Booking.com、Yahoo!等MySQL用戶相比單次查詢的性能對吞吐量更感興趣(我是這么認(rèn)為的)。但大多數(shù)的MySQL用戶(95%)不會有吞吐量的問題,但會有查詢性能問題(在這我假定對Oracle,DB2,MS-SQL Server,PostgreSQL等也是這樣)。

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

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

第一個假設(shè):“過去的時光總是更好”是絕對不正確的。 MySQL的4.0和4.1只是個特例。基于MySQL5.0粗略估計的趨勢是:隨著時間的推移(新版本)單一的查詢性能會變得更差。我想這也適用于其他數(shù)據(jù)庫...

像一些聲稱:“我們擁有最快的MySQL”或“我們已經(jīng)聘請了整個優(yōu)化團(tuán)隊”并不需要反映在單一查詢的性能上。至少不會為了某一個特定的查詢。

因此,概要的說:如果您升級(MySQL的< - > Percona的< - > MariaDB的),則需要很小心的測試!其中陷阱是不可預(yù)測的。較新的MySQL版本或許可以增加你的應(yīng)用程序的性能。孩子,不要太相信市場。

一些假象

我們這個小小的測試過程中已經(jīng)發(fā)現(xiàn)了一些假象:

在MySQL 5.0中引入的優(yōu)化(不是在優(yōu)化!?!),大大加快單一特定的查詢。

MariaDB的5.2和5.3在這個特定的查詢表現(xiàn)很糟糕。

我不知道為什么Galera集群已經(jīng)顯示出5.5是最好的那個版本。這不是故意的或操縱的!這結(jié)果真是運氣不佳。但我喜歡它! :-)

MySQL的5.6在這些查詢上似乎有一些問題。可能由Oracle給MySQL帶來了太多的改善的原因?(╯‵□′)╯︵┻━┻

Percona版本的5.6這些查詢上比普通的MySQL有時會表現(xiàn)更好,但有時候什么Oracle優(yōu)化使得Percona的速度大幅放緩。因此,顯示出 特別壞的結(jié)果。我不知道為什么。我第一反應(yīng)是外部的影響。但我有能力重現(xiàn)這種糟搞情況(一次)。所以我認(rèn)為這一定有什么在Percona的內(nèi)部(例如 AHI?)。

最后

兩國交戰(zhàn)不斬來使!

如果您不滿意這里已經(jīng)發(fā)布的計算結(jié)果想重新計算。或者這里遺漏了什么,煩請告知本人。

如果您對這個結(jié)論不認(rèn)同也請告訴我。我也好溫故而知新

今天的這個測試很有趣。我的MyEnv對于這個測試也提供了很多幫助。

如果您需要我們?yōu)槟鲞@個測試,請聯(lián)系我們。我們的咨詢團(tuán)隊consulting將非常樂意為您提供各種問題的解答。

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

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

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

2011-07-06 14:18:40

Percona SerMySQL

2011-04-28 09:49:56

SQLwith子查詢

2011-04-15 10:26:38

JavaMVC

2013-04-03 10:04:36

MySQL 5.6

2012-12-03 10:26:51

Scala

2009-05-25 08:39:08

iPhone蘋果移動OS

2011-05-18 14:52:04

XML

2009-07-01 18:12:18

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

2015-02-05 09:25:51

HTTPSSPDYHTTP2

2020-07-27 08:24:42

編程語言C語言Java

2010-03-10 16:35:23

Python編程語言

2023-11-20 10:34:09

語言

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

2009-12-16 14:10:12

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

2015-03-09 10:40:44

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

2014-08-20 09:49:50

虛擬機(jī)Linux Conta

2017-12-14 10:16:01

CaddySSLDockerNginx

2024-06-24 07:00:00

C++RustGo
點贊
收藏

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

主站蜘蛛池模板: 一本色道精品久久一区二区三区 | 毛片网在线观看 | 国产日韩欧美一区二区在线播放 | 欧美高清一区 | 婷婷色在线 | 播放一级黄色片 | h视频免费在线观看 | 久久这里只有精品首页 | 日本精品一区二区在线观看 | 欧美精品福利视频 | 一区二区三区免费网站 | 精品一级| 黄色三级在线播放 | 日韩精品一区中文字幕 | 午夜理伦三级理论三级在线观看 | 在线午夜 | 亚洲入口| 中文字幕在线播放不卡 | 日韩精品av | 国产一区二区小视频 | 日本在线综合 | 精品国产乱码久久久久久88av | 看片地址| 欧美日韩一二区 | 黄色一级视频免费 | 精品欧美一区二区三区久久久 | 国产精品久久久久久久久久久久久 | 黄色大片在线免费观看 | 视频二区 | 国产在线精品一区二区三区 | 欧美激情在线观看一区二区三区 | 日韩在线不卡视频 | 日韩在线免费视频 | 精品视频网 | 欧美激情久久久 | 欧美一级三级在线观看 | 亚洲一区二区久久 | 99久久精品免费看国产四区 | 精品一区二区在线看 | 亚洲免费一区 | 久久99久久 |