作者:風(fēng)過(guò)無(wú)痕的博客
場(chǎng)景
用的數(shù)據(jù)庫(kù)是mysql5.6,下面簡(jiǎn)單的介紹下場(chǎng)景。
課程表
createtableCourse( c_idintPRIMARYKEY, namevarchar(10) )
數(shù)據(jù)100條。
學(xué)生表
createtableStudent( idintPRIMARYKEY, namevarchar(10) )
數(shù)據(jù)70000條。
學(xué)生成績(jī)表
CREATEtableSC( sc_idintPRIMARYKEY, s_idint, c_idint, scoreint )
數(shù)據(jù)70w條。
查詢目的:
查找語(yǔ)文考100分的考生。
查詢語(yǔ)句:
selects.*fromStudents wheres.s_idin( selects_id fromSCsc wheresc.c_id=0andsc.score=100)
執(zhí)行時(shí)間:30248.271s
暈,為什么這么慢,先來(lái)查看下查詢計(jì)劃:
EXPLAIN selects.*fromStudents wheres.s_idin( selects_id fromSCsc wheresc.c_id=0andsc.score=100)

發(fā)現(xiàn)沒有用到索引,type全是ALL,那么首先想到的就是建立一個(gè)索引,建立索引的字段當(dāng)然是在where條件的字段。
先給sc表的c_id和score建個(gè)索引。
CREATEindexsc_c_id_indexonSC(c_id); CREATEindexsc_score_indexonSC(score);
再次執(zhí)行上述查詢語(yǔ)句,時(shí)間為: 1.054s
快了3w多倍,大大縮短了查詢時(shí)間,看來(lái)索引能極大程度的提高查詢效率,建索引很有必要,很多時(shí)候都忘記建。
索引了,數(shù)據(jù)量小的的時(shí)候壓根沒感覺,這優(yōu)化的感覺挺爽。
但是1s的時(shí)間還是太長(zhǎng)了,還能進(jìn)行優(yōu)化嗎,仔細(xì)看執(zhí)行計(jì)劃:
查看優(yōu)化后的sql:
SELECT `YSB`.`s`.`s_id`AS`s_id`, `YSB`.`s`.`name`AS`name` FROM `YSB`.`Student``s` WHERE ( `YSB`.`s`.`s_id`,( SELECT 1 FROM `YSB`.`SC``sc` WHERE ( (`YSB`.`sc`.`c_id`=0) AND(`YSB`.`sc`.`score`=100) AND( (`YSB`.`s`.`s_id`)=`YSB`.`sc`.`s_id` ) ) ) )
補(bǔ)充:這里有網(wǎng)友問怎么查看優(yōu)化后的語(yǔ)句。
方法如下:
在命令窗口執(zhí)行
有type=all
按照我之前的想法,該sql的執(zhí)行的順序應(yīng)該是先執(zhí)行子查詢。
selects_id fromSCsc wheresc.c_id=0andsc.score=100
耗時(shí):0.001s
得到如下結(jié)果:
然后再執(zhí)行
selects.* fromStudents wheres.s_idin(7,29,5000)
耗時(shí):0.001s
這樣就是相當(dāng)快了啊,Mysql竟然不是先執(zhí)行里層的查詢,而是將sql優(yōu)化成了exists子句,并出現(xiàn)了EPENDENT SUBQUERY,
mysql是先執(zhí)行外層查詢,再執(zhí)行里層的查詢,這樣就要循環(huán)70007*8次。
那么改用連接查詢呢?
SELECTs.*from Students INNERJOINSCsc onsc.s_id=s.s_id wheresc.c_id=0andsc.score=100
這里為了重新分析連接查詢的情況,先暫時(shí)刪除索引sc_c_id_index,sc_score_index 。
執(zhí)行時(shí)間是:0.057s
效率有所提高,看看執(zhí)行計(jì)劃:
這里有連表的情況出現(xiàn),我猜想是不是要給sc表的s_id建立個(gè)索引
CREATEindexsc_s_id_indexonSC(s_id); showindexfromSC

在執(zhí)行連接查詢
時(shí)間: 1.076s, 竟然時(shí)間還變長(zhǎng)了,什么原因?查看執(zhí)行計(jì)劃:
優(yōu)化后的查詢語(yǔ)句為:
SELECT `YSB`.`s`.`s_id`AS`s_id`, `YSB`.`s`.`name`AS`name` FROM `YSB`.`Student``s` JOIN`YSB`.`SC``sc` WHERE ( ( `YSB`.`sc`.`s_id`=`YSB`.`s`.`s_id` ) AND(`YSB`.`sc`.`score`=100) AND(`YSB`.`sc`.`c_id`=0) )
貌似是先做的連接查詢,再進(jìn)行的where條件過(guò)濾。
回到前面的執(zhí)行計(jì)劃:
這里是先做的where條件過(guò)濾,再做連表,執(zhí)行計(jì)劃還不是固定的,那么我們先看下標(biāo)準(zhǔn)的sql執(zhí)行順序:
正常情況下是先join再進(jìn)行where過(guò)濾,但是我們這里的情況,如果先join,將會(huì)有70w條數(shù)據(jù)發(fā)送join做操,因此先執(zhí)行where 。
過(guò)濾是明智方案,現(xiàn)在為了排除mysql的查詢優(yōu)化,我自己寫一條優(yōu)化后的sql 。
SELECT s.* FROM ( SELECT * FROM SCsc WHERE sc.c_id=0 ANDsc.score=100 )t INNERJOINStudentsONt.s_id=s.s_id
即先執(zhí)行sc表的過(guò)濾,再進(jìn)行表連接,執(zhí)行時(shí)間為:0.054s 。
和之前沒有建s_id索引的時(shí)間差不多。
查看執(zhí)行計(jì)劃:
先提取sc再連表,這樣效率就高多了,現(xiàn)在的問題是提取sc的時(shí)候出現(xiàn)了掃描表,那么現(xiàn)在可以明確需要建立相關(guān)索引。
CREATEindexsc_c_id_indexonSC(c_id); CREATEindexsc_score_indexonSC(score);
再執(zhí)行查詢:
SELECT s.* FROM ( SELECT * FROM SCsc WHERE sc.c_id=0 ANDsc.score=100 )t INNERJOINStudentsONt.s_id=s.s_id
執(zhí)行時(shí)間為:0.001s,這個(gè)時(shí)間相當(dāng)靠譜,快了50倍。
執(zhí)行計(jì)劃:
我們會(huì)看到,先提取sc,再連表,都用到了索引。
那么再來(lái)執(zhí)行下sql。
SELECTs.*from Students INNERJOINSCsc onsc.s_id=s.s_id wheresc.c_id=0andsc.score=100
執(zhí)行時(shí)間0.001s
執(zhí)行計(jì)劃:
這里是mysql進(jìn)行了查詢語(yǔ)句優(yōu)化,先執(zhí)行了where過(guò)濾,再執(zhí)行連接操作,且都用到了索引。
2015-04-30日補(bǔ)充:最近又重新導(dǎo)入一些生產(chǎn)數(shù)據(jù),經(jīng)測(cè)試發(fā)現(xiàn),前幾天優(yōu)化完的sql執(zhí)行效率又變低了。
調(diào)整內(nèi)容為SC表的數(shù)據(jù)增長(zhǎng)到300W,學(xué)生分?jǐn)?shù)更為離散。
先回顧下:
show index from SC
執(zhí)行sql
SELECTs.*from Students INNERJOINSCsc onsc.s_id=s.s_id wheresc.c_id=81andsc.score=84
執(zhí)行時(shí)間:0.061s,這個(gè)時(shí)間稍微慢了點(diǎn)。執(zhí)行計(jì)劃:
這里用到了intersect并集操作,即兩個(gè)索引同時(shí)檢索的結(jié)果再求并集,再看字段score和c_id的區(qū)分度。
單從一個(gè)字段看,區(qū)分度都不是很大,從SC表檢索,c_id=81檢索的結(jié)果是70001,score=84的結(jié)果是39425。
而c_id=81 and score=84 的結(jié)果是897,即這兩個(gè)字段聯(lián)合起來(lái)的區(qū)分度是比較高的,因此建立聯(lián)合索引查詢效率。
將會(huì)更高,從另外一個(gè)角度看,該表的數(shù)據(jù)是300w,以后會(huì)更多,就索引存儲(chǔ)而言,都是不小的數(shù)目,隨著數(shù)據(jù)量的。
增加,索引就不能全部加載到內(nèi)存,而是要從磁盤去讀取,這樣索引的個(gè)數(shù)越多,讀磁盤的開銷就越大,因此根據(jù)具體。
業(yè)務(wù)情況建立多列的聯(lián)合索引是必要的,那么我們來(lái)試試吧。
altertableSCdropindexsc_c_id_index; altertableSCdropindexsc_score_index; createindexsc_c_id_score_indexonSC(c_id,score);
執(zhí)行上述查詢語(yǔ)句,消耗時(shí)間為:0.007s,這個(gè)速度還是可以接收的。
執(zhí)行計(jì)劃:
該語(yǔ)句的優(yōu)化暫時(shí)告一段落。
總結(jié)
mysql嵌套子查詢效率確實(shí)比較低
可以將其優(yōu)化成連接查詢
連接表時(shí),可以先用where條件對(duì)表進(jìn)行過(guò)濾,然后做表連接
(雖然mysql會(huì)對(duì)連表語(yǔ)句做優(yōu)化)
建立合適的索引,必要時(shí)建立多列聯(lián)合索引
學(xué)會(huì)分析sql執(zhí)行計(jì)劃,mysql會(huì)對(duì)sql進(jìn)行優(yōu)化,所以分析執(zhí)行計(jì)劃很重要
索引優(yōu)化
上面講到子查詢的優(yōu)化,以及如何建立索引,而且在多個(gè)字段索引時(shí),分別對(duì)字段建立了單個(gè)索引。
后面發(fā)現(xiàn)其實(shí)建立聯(lián)合索引效率會(huì)更高,尤其是在數(shù)據(jù)量較大,單個(gè)列區(qū)分度不高的情況下。
單列索引
查詢語(yǔ)句如下:
select*fromuser_test_copywheresex=2andtype=2andage=10
索引:
CREATEindexuser_test_index_sexonuser_test_copy(sex); CREATEindexuser_test_index_typeonuser_test_copy(type); CREATEindexuser_test_index_ageonuser_test_copy(age);
分別對(duì)sex,type,age字段做了索引,數(shù)據(jù)量為300w,查詢時(shí)間:0.415s執(zhí)行計(jì)劃:
發(fā)現(xiàn) type=index_merge
這是mysql對(duì)多個(gè)單列索引的優(yōu)化,對(duì)結(jié)果集采用intersect并集操作
多列索引
我們可以在這3個(gè)列上建立多列索引,將表copy一份以便做測(cè)試
createindexuser_test_index_sex_type_ageonuser_test(sex,type,age);
查詢語(yǔ)句:
select*fromuser_testwheresex=2andtype=2andage=10
執(zhí)行時(shí)間:0.032s,快了10多倍,且多列索引的區(qū)分度越高,提高的速度也越多
執(zhí)行計(jì)劃:
最左前綴
多列索引還有最左前綴的特性:
執(zhí)行一下語(yǔ)句:
select*fromuser_testwheresex=2 select*fromuser_testwheresex=2andtype=2 select*fromuser_testwheresex=2andage=10
都會(huì)使用到索引,即索引的第一個(gè)字段sex要出現(xiàn)在where條件中
索引覆蓋
就是查詢的列都建立了索引,這樣在獲取結(jié)果集的時(shí)候不用再去磁盤獲取其它列的數(shù)據(jù),直接返回索引數(shù)據(jù)即可
如:
selectsex,type,agefromuser_testwheresex=2andtype=2andage=10
執(zhí)行時(shí)間:0.003s
要比取所有字段快的多
排序
select*fromuser_testwheresex=2andtype=2ORDERBYuser_name
時(shí)間:0.139s
在排序字段上建立索引會(huì)提高排序的效率
createindexuser_name_indexonuser_test(user_name)
最后附上一些sql調(diào)優(yōu)的總結(jié),以后有時(shí)間再深入研究
列類型盡量定義成數(shù)值類型,且長(zhǎng)度盡可能短,如主鍵和外鍵,類型字段等等
建立單列索引
根據(jù)需要建立多列聯(lián)合索引
當(dāng)單個(gè)列過(guò)濾之后還有很多數(shù)據(jù),那么索引的效率將會(huì)比較低,即列的區(qū)分度較低,
那么如果在多個(gè)列上建立索引,那么多個(gè)列的區(qū)分度就大多了,將會(huì)有顯著的效率提高。
根據(jù)業(yè)務(wù)場(chǎng)景建立覆蓋索引
只查詢業(yè)務(wù)需要的字段,如果這些字段被索引覆蓋,將極大的提高查詢效率
多表連接的字段上需要建立索引這樣可以極大的提高表連接的效率
where條件字段上需要建立索引
排序字段上需要建立索引
分組字段上需要建立索引
Where條件上不要使用運(yùn)算函數(shù),以免索引失效
審核編輯:湯梓紅
-
SQL
+關(guān)注
關(guān)注
1文章
782瀏覽量
44952 -
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3907瀏覽量
65957 -
MySQL
+關(guān)注
關(guān)注
1文章
850瀏覽量
27728
原文標(biāo)題:一次非常有意思的 SQL 優(yōu)化經(jīng)歷:從 30248.271s 到 0.001s
文章出處:【微信號(hào):DBDevs,微信公眾號(hào):數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
PCB Layout的第一次經(jīng)歷分享
數(shù)據(jù)庫(kù)SQL的優(yōu)化

一次電池為什么不能被充電?
循環(huán)充放電一次就是少一次壽命嗎?
電池循環(huán)充放電一次就是少一次壽命嗎?
SQL后悔藥,SQL性能優(yōu)化和SQL規(guī)范優(yōu)雅
記一次CH552不識(shí)別無(wú)法下載解決辦法

記一次組合拳滲透測(cè)試
一文終結(jié)SQL子查詢優(yōu)化

評(píng)論