在任何一個數(shù)據(jù)庫中，查詢優(yōu)化都是不可避免的一個話題。對于數(shù)據(jù)庫工程師來說，優(yōu)化工作是最有挑戰(zhàn)性的工作。MySQL開源數(shù)據(jù)庫也不例外

本站收錄這篇文章提升MySQL查詢效率及查詢速度優(yōu)化的4個方法，詳細(xì)解說文章中相關(guān)查詢 效率 查詢速度 優(yōu)化 技術(shù)與知識，歡迎能給大家一些在這方面的支持和幫助！下面是詳細(xì)內(nèi)容：

眾所周知，在任何一個數(shù)據(jù)庫中，查詢優(yōu)化都是不可避免的一個話題。對于數(shù)據(jù)庫工程師來說，優(yōu)化工作是最有挑戰(zhàn)性的工作。MySQL開源數(shù)據(jù)庫也不例外。其實筆者認(rèn)為，數(shù)據(jù)庫優(yōu)化并沒有大家所想象的那么苦難。通常情況下，大家可以從以下四個細(xì)節(jié)出發(fā)來做好MySQL數(shù)據(jù)庫的查詢優(yōu)化工作。

一、利用EXPLAIN關(guān)鍵字來評估查詢語句中的缺陷

如下圖所示，現(xiàn)在筆者在數(shù)據(jù)庫中執(zhí)行了一條簡單的Select查詢語句，從一個表格中查詢所有信息。現(xiàn)在數(shù)據(jù)庫管理員想知道，數(shù)據(jù)庫在執(zhí)行這條語句時，做了哪些工作或者說想知道，這條查詢語句有沒有進(jìn)一步優(yōu)化的可能。如果要了解這個信息的話，就可以在查詢語句中加入一個Explain關(guān)鍵字。

通過Select查詢語句可以從數(shù)據(jù)庫中查詢某個表中的數(shù)據(jù)。但是這條語句執(zhí)行的效率如何是否還有優(yōu)化的余地這些內(nèi)容是無法從上面這個簡單的查詢語句中獲得的。為了了解更加詳細(xì)的信息，需要加入Explain關(guān)鍵字。如下圖所示：

加入Explain關(guān)鍵字之后，系統(tǒng)并沒有查詢出表格中的數(shù)據(jù)，而只是顯示了查詢過程中的一些信息。這些信息對于我們后續(xù)進(jìn)行數(shù)據(jù)庫查詢優(yōu)化非常有幫助。從上面這個信息中我們可以看出，用戶只是進(jìn)行來一個簡單的查詢。在這個查詢中，沒有用到任何索引、關(guān)鍵字等內(nèi)容，也沒有用到Where條件語句。為此這個查詢語句并不是很合理。雖然其可以找到最后正確的結(jié)果，不過其查詢效率可能并不是很明顯。為此數(shù)據(jù)庫專家可以根據(jù)上面顯示的信息來進(jìn)行優(yōu)化。如果我們現(xiàn)在在查詢語句中加入一條Where語句，那么又會有什么樣的結(jié)果呢如下圖所示。

此時在最后一個Extra字段中，系統(tǒng)就會顯示已經(jīng)使用了Where語句。在進(jìn)行數(shù)據(jù)庫優(yōu)化中，我們需要抓住結(jié)果中的NULL字段或者空白內(nèi)容的字段。這些地方往往是我們進(jìn)行優(yōu)化的重點。如上圖所示，我們可以給這條Select語句進(jìn)行如下的優(yōu)化：在表中設(shè)置關(guān)鍵字或者索引，來提高查詢的效率。

二、數(shù)據(jù)比較時采用相同類型的列以提高查詢效率

在數(shù)據(jù)查詢時，有時候會在條件語句中加入判斷的條件。如現(xiàn)在有兩張表：用戶基本信息表和用戶權(quán)限表，兩者通過用戶編號作為關(guān)聯(lián)?，F(xiàn)在需要查詢出每個用戶對應(yīng)什么樣的權(quán)限，此時就要通過用戶編號作為查詢條件來進(jìn)行查詢?，F(xiàn)在假設(shè)用戶基本信息表中的用戶編號字段為CHAR類型的;而用戶權(quán)限表中的用戶編號是VARCHAR類型的。這兩個數(shù)據(jù)類型雖然都是字符型，但是不是同一種類型?，F(xiàn)在對這連個表執(zhí)行關(guān)聯(lián)查詢，其查詢的效率如何呢首先需要確定的一點是，雖然他們兩個是不同類型的字符型數(shù)據(jù)，不過是相互兼容的。最后仍然可以得到正確的結(jié)果。明確了這一點之后，我們再來考慮，能否對這個查詢語句進(jìn)行優(yōu)化呢

我們再假設(shè)一下?，F(xiàn)在這兩個表的用戶編號的數(shù)據(jù)類型都是CHAR。現(xiàn)在再對這兩個表進(jìn)行關(guān)聯(lián)查詢，得到的結(jié)果是否相同呢我們測試的結(jié)果是，查詢的結(jié)果是相同的，但是其所花費的時間是不同的。而且隨著數(shù)據(jù)量的增加，兩個查詢所相差的時間會越來越長。從這里可以知道，雖然這兩個查詢語句是等價的，但是其查詢的效率不同。

在MySQL數(shù)據(jù)庫中，雖然相互兼容的數(shù)據(jù)類型可以進(jìn)行相互比較。但是其查詢的效率會有所影響。從提高數(shù)據(jù)庫查詢效率的角度出發(fā)，筆者建議在查詢條件語句中最好比較具有相同類型的列。在同等條件下，相同的列類型比不同類型的列能夠提供更好的性能。特別是在數(shù)據(jù)量比較多的數(shù)據(jù)庫中，這尤其重要。

不過這個優(yōu)化需要涉及到數(shù)據(jù)表的列類型。為此在數(shù)據(jù)表進(jìn)行設(shè)計時，就需要考慮這一點。如針對上面這個案例，我們可以在兩個表中專門設(shè)置一個用戶ID列?？梢允褂谜麛?shù)類型的序列，讓系統(tǒng)進(jìn)行自動編號。然后在查詢時通過這個用戶ID列來進(jìn)行比較，而不是通過原來的用戶編號列進(jìn)行比較。相對來說，這么操作查詢的效率會更高。

三、在Like關(guān)鍵字的起始處通配符要謹(jǐn)慎使用

在實際工作中，筆者發(fā)現(xiàn)不少數(shù)據(jù)庫管理員有一個不好的習(xí)慣。他們在使用Like等關(guān)鍵字時，通配符會亂用。如現(xiàn)在用戶需要查找所有以“LOOK”為前綴的產(chǎn)品信息。用戶在查詢時，會習(xí)慣性的使用下面的語句進(jìn)行查詢：like “%LOOK%”。這個條件語句會查詢出所有品名中有LOOK這個單詞的紀(jì)錄，而不是查詢出以LOOK為前綴的產(chǎn)品信息。

雖然最終的結(jié)果可能是相同的。但是兩者的查詢效率不同。其實這很大一部分原因是客戶端應(yīng)用程序設(shè)計不當(dāng)所造成的。如在客戶端應(yīng)用程序設(shè)計時，系統(tǒng)會默認(rèn)顯示一個%符號。如下圖所示。

這么設(shè)計的本意是好的，讓系統(tǒng)能夠支持模糊查詢。但是用戶在實際操作起來，就可以有問題。如用戶在查詢時，不會在%號前面輸入LOOK這個單詞，而是在%后面輸入LOOK這個單詞。因為在查詢時，光標(biāo)會自動定位到%號后面。通常情況下，用戶在輸入時不會再去調(diào)整光標(biāo)的位置。此時就出現(xiàn)了上面所說的這種情況。

為此筆者建議，在Like等關(guān)鍵字后面如果需要用到通配符的話，要非常的謹(jǐn)慎。特別是從大量數(shù)據(jù)中查找紀(jì)錄時，這個通配符的位置一定要用對地方。在起始處能夠不同通配符的話，盡量不要使用通配符。

四、盡量使用其它形式來代替Like關(guān)鍵字

上面提到在使用Like關(guān)鍵字時需要注意通配符的位置。其實從查詢效率來看，我們不僅需要注意通配符的位置，而且能夠不用Like關(guān)鍵字最好就不用。其實在SQL語句中，可以利用其他方式來代替Like關(guān)鍵字。如現(xiàn)在有一個產(chǎn)品表，其編號為6位?，F(xiàn)在需要查詢以9開頭的產(chǎn)品編號。這該怎么操作呢

一是可以通過使用Like關(guān)鍵字，如LIKE “9%”。注意這個通配符的位置。這個條件語句可以查到所需要的結(jié)果。但是從性能優(yōu)化的角度看，這條語句不是很好的處理方式。我們還可以通過一些折中的方式來實現(xiàn)。

二是通過比較符號來實現(xiàn)。如可以使用Value>=900000 and Value<=999999這種方式來實現(xiàn)。雖然兩者的查詢的結(jié)果是相同的。但是查詢的時間這條語句要比上面這個采用Like符號的語句要短的多。

總結(jié)

到此這篇關(guān)于提升MySQL查詢效率及查詢速度優(yōu)化的四個方法的文章就介紹到這了,更多相關(guān)MySQL查詢效率提升及優(yōu)化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論