MySQL 大表的count()優(yōu)化實(shí)現(xiàn)
以下是基于我結(jié)合B+樹的數(shù)據(jù)結(jié)構(gòu)和對(duì)實(shí)驗(yàn)結(jié)果的推測(cè)作出的判斷,如有錯(cuò)誤,懇請(qǐng)指正!
今天實(shí)驗(yàn)了一下MySQL的count()操作優(yōu)化, 以下討論基于mysql5.7 InnoDB存儲(chǔ)引擎. x86 windows操作系統(tǒng)。
創(chuàng)建的表的結(jié)構(gòu)如下(數(shù)據(jù)量為100萬):
首先是關(guān)于mysql的count(*),count(PK), count(1)哪個(gè)快的問題。
實(shí)現(xiàn)結(jié)果如下:
并沒有什么區(qū)別!加上了WHERE子句之后3個(gè)查詢的時(shí)間也是相同的,我就不貼圖片了。
之前在公司的時(shí)候就寫過一個(gè)select count(*) from table
的SQL語句,在數(shù)據(jù)多的時(shí)候非常慢。所以要怎么優(yōu)化呢?
這要從InnoDB的索引說起, InnoDB的索引是B+Tree。
對(duì)主鍵索引來說:它只有在葉子節(jié)點(diǎn)上存儲(chǔ)數(shù)據(jù),它的key是主鍵,并且value為整條數(shù)據(jù)。
對(duì)輔助索引來說:key為建索引的列,value為主鍵。
這給我們兩個(gè)信息:
1. 根據(jù)主鍵會(huì)查到整條數(shù)據(jù)
2. 根據(jù)輔助索引只能查到主鍵,然后必須通過主鍵再查到剩余信息。
所以如果要優(yōu)化count(*)操作的話,我們需要找一個(gè)短小的列,為它建立輔助索引。
在我的例子中就是status
,雖然它的”severelity”幾乎為0.
先建立索引:ALTER TABLE test1 ADD INDEX (
status);
然后查詢,如下圖:
可以看到,查詢時(shí)間從3.35s下降到了0.26s,查詢速度提升近13倍。
如果索引是str
這一列,結(jié)果又會(huì)是怎么樣呢?
先建立索引: alter table test1 add index (str)
結(jié)果如下:
可以看到,時(shí)間為0.422s,也很快,但是比起status
這列還是有著1.5倍左右的差距。
再大膽一點(diǎn)做個(gè)實(shí)驗(yàn),我把status
這列的索引刪掉,建立一個(gè)status
和left(omdb,200)
(這一列平均1000個(gè)字符)的聯(lián)合索引,然后看查詢時(shí)間。
建立索引: alter table test1 add index (
status,omdb(200))
結(jié)果如下:
時(shí)間為1.172s
alter table test1 add index (status,imdbid);
補(bǔ)充!!
要注意索引失效的情況!
建立了索引后正常的的樣子:
可以看到key_len為6, Extra的說明是using index.
而如果索引失效的話:
索引失效有很多種情況,比如使用函數(shù),!=操作等,具體請(qǐng)參考官方文檔。
對(duì)MySQL沒有很深的研究,以上是基于我結(jié)合B+樹的數(shù)據(jù)結(jié)構(gòu)和對(duì)實(shí)驗(yàn)結(jié)果的推測(cè)作出的判斷,如有錯(cuò)誤,懇請(qǐng)指正!
到此這篇關(guān)于MySQL 大表的count()優(yōu)化實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)MySQL 大表count()優(yōu)化內(nèi)容請(qǐng)搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站!
版權(quán)聲明:本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有,歡迎引用、轉(zhuǎn)載,請(qǐng)保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站,禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像,否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來,僅供學(xué)習(xí)參考,不代表本站立場(chǎng),如有內(nèi)容涉嫌侵權(quán),請(qǐng)聯(lián)系alex-e#qq.com處理。