MySQL 索引及查詢優化總結

本文由雲+社區發表

文章《MySQL查詢分析》講述了使用MySQL慢查詢和explain命令來定位mysql性能瓶頸的方法，定位出性能瓶頸的sql語句後，則須要對低效的sql語句進行優化。本文主要討論MySQL索引原理及經常使用的sql查詢優化。

一個簡單的對比測試

前面的案例中，c2c_zwdb.t_file_count表只有一個自增id，FFileName字段未加索引的sql執行狀況以下：

在上圖中，type=all，key=null，rows=33777。該sql未使用索引，是一個效率很是低的全表掃描。若是加上聯合查詢和其餘一些約束條件，數據庫會瘋狂的消耗內存，而且會影響前端程序的執行。

這時給FFileName字段添加一個索引：

alter table c2c_zwdb.t_file_count add index index_title(FFileName);

再次執行上述查詢語句，其對比很明顯：

在該圖中，type=ref，key=索引名（index_title），rows=1。該sql使用了索引index_title，且是一個常數掃描，根據索引只掃描了一行。

比起未加索引的狀況，加了索引後，查詢效率對比很是明顯。

MySQL索引

經過上面的對比測試能夠看出，索引是快速搜索的關鍵。MySQL索引的創建對於MySQL的高效運行是很重要的。對於少許的數據，沒有合適的索引影響不是很大，可是，當隨着數據量的增長，性能會急劇降低。若是對多列進行索引(組合索引)，列的順序很是重要，MySQL僅能對索引最左邊的前綴進行有效的查找。

下面介紹幾種常見的MySQL索引類型。

索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表能夠有多個單列索引，但這不是組合索引。組合索引，即一個索引包含多個列。

一、MySQL索引類型

(1) 主鍵索引 PRIMARY KEY

它是一種特殊的惟一索引，不容許有空值。通常是在建表的時候同時建立主鍵索引。

固然也能夠用 ALTER 命令。記住：一個表只能有一個主鍵。

(2) 惟一索引 UNIQUE

惟一索引列的值必須惟一，但容許有空值。若是是組合索引，則列值的組合必須惟一。能夠在建立表的時候指定，也能夠修改表結構，如：

ALTER TABLE table_name ADD UNIQUE (column)

(3) 普通索引 INDEX

這是最基本的索引，它沒有任何限制。能夠在建立表的時候指定，也能夠修改表結構，如：

ALTER TABLE table_name ADD INDEX index_name (column)

(4) 組合索引 INDEX

組合索引，即一個索引包含多個列。能夠在建立表的時候指定，也能夠修改表結構，如：

ALTER TABLE table_name ADD INDEX index_name(column1, column2, column3)

(5) 全文索引 FULLTEXT

全文索引（也稱全文檢索）是目前搜索引擎使用的一種關鍵技術。它可以利用分詞技術等多種算法智能分析出文本文字中關鍵字詞的頻率及重要性，而後按照必定的算法規則智能地篩選出咱們想要的搜索結果。

能夠在建立表的時候指定，也能夠修改表結構，如：

ALTER TABLE table_name ADD FULLTEXT (column)

二、索引結構及原理

mysql中廣泛使用B+Tree作索引，但在實現上又根據聚簇索引和非聚簇索引而不一樣，本文暫不討論這點。

b+樹介紹

下面這張b+樹的圖片在不少地方能夠看到，之因此在這裏也選取這張，是由於以爲這張圖片能夠很好的詮釋索引的查找過程。

如上圖，是一顆b+樹。淺藍色的塊咱們稱之爲一個磁盤塊，能夠看到每一個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），如磁盤塊1包含數據項17和35，包含指針P一、P二、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。

真實的數據存在於葉子節點，即三、五、九、十、1三、1五、2八、2九、3六、60、7五、7九、90、99。非葉子節點不存儲真實的數據，只存儲指引搜索方向的數據項，如1七、35並不真實存在於數據表中。

查找過程

在上圖中，若是要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找肯定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間由於很是短（相比磁盤的IO）能夠忽略不計，經過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，經過指針加載磁盤塊8到內存，發生第三次IO，同時內存中作二分查找找到29，結束查詢，總計三次IO。真實的狀況是，3層的b+樹能夠表示上百萬的數據，若是上百萬的數據查找只須要三次IO，性能提升將是巨大的，若是沒有索引，每一個數據項都要發生一次IO，那麼總共須要百萬次的IO，顯然成本很是很是高。

性質

(1) 索引字段要儘可能的小。

經過上面b+樹的查找過程，或者經過真實的數據存在於葉子節點這個事實可知，IO次數取決於b+數的高度h。

假設當前數據表的數據量爲N，每一個磁盤塊的數據項的數量是m，則樹高h=㏒(m+1)N，當數據量N必定的狀況下，m越大，h越小；

而m = 磁盤塊的大小/數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的；若是數據項佔的空間越小，數據項的數量m越多，樹的高度h越低。這就是爲何每一個數據項，即索引字段要儘可能的小，好比int佔4字節，要比bigint8字節少一半。

(2) 索引的最左匹配特性。

當b+樹的數據項是複合的數據結構，好比(name,age,sex)的時候，b+數是按照從左到右的順序來創建搜索樹的，好比當(張三,20,F)這樣的數據來檢索的時候，b+樹會優先比較name來肯定下一步的所搜方向，若是name相同再依次比較age和sex，最後獲得檢索的數據；但當(20,F)這樣的沒有name的數據來的時候，b+樹就不知道下一步該查哪一個節點，由於創建搜索樹的時候name就是第一個比較因子，必需要先根據name來搜索才能知道下一步去哪裏查詢。好比當(張三,F)這樣的數據來檢索時，b+樹能夠用name來指定搜索方向，但下一個字段age的缺失，因此只能把名字等於張三的數據都找到，而後再匹配性別是F的數據了， 這個是很是重要的性質，即索引的最左匹配特性。

建索引的幾大原則

(1) 最左前綴匹配原則

對於多列索引，老是從索引的最前面字段開始，接着日後，中間不能跳過。好比建立了多列索引(name,age,sex)，會先匹配name字段，再匹配age字段，再匹配sex字段的，中間不能跳過。mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就中止匹配。

通常，在建立多列索引時，where子句中使用最頻繁的一列放在最左邊。

看一個補符合最左前綴匹配原則和符合該原則的對比例子。

實例：表c2c_db.t_credit_detail建有索引(Flistid,Fbank_listid)

不符合最左前綴匹配原則的sql語句：

select * from t_credit_detail where Fbank_listid='201108010000199'G

該sql直接用了第二個索引字段Fbank_listid，跳過了第一個索引字段Flistid，不符合最左前綴匹配原則。用explain命令查看sql語句的執行計劃，以下圖：

從上圖能夠看出，該sql未使用索引，是一個低效的全表掃描。

符合最左前綴匹配原則的sql語句：

select * from t_credit_detail where Flistid='2000000608201108010831508721' and Fbank_listid='201108010000199'G

該sql先使用了索引的第一個字段Flistid，再使用索引的第二個字段Fbank_listid，中間沒有跳過，符合最左前綴匹配原則。用explain命令查看sql語句的執行計劃，以下圖：

從上圖能夠看出，該sql使用了索引，僅掃描了一行。

對比可知，符合最左前綴匹配原則的sql語句比不符合該原則的sql語句效率有極大提升，從全表掃描上升到了常數掃描。

(2) 儘可能選擇區分度高的列做爲索引。

好比，咱們會選擇學號作索引，而不會選擇性別來作索引。

(3) =和in能夠亂序

好比a = 1 and b = 2 and c = 3，創建(a,b,c)索引能夠任意順序，mysql的查詢優化器會幫你優化成索引能夠識別的形式。

(4) 索引列不能參與計算，保持列「乾淨」

好比：Flistid+1>‘2000000608201108010831508721‘。緣由很簡單，假如索引列參與計算的話，那每次檢索時，都會先將索引計算一次，再作比較，顯然成本太大。

(5) 儘可能的擴展索引，不要新建索引。

好比表中已經有a的索引，如今要加(a,b)的索引，那麼只須要修改原來的索引便可。

索引的不足

雖然索引能夠提升查詢效率，但索引也有本身的不足之處。

索引的額外開銷：

(1) 空間：索引須要佔用空間；

(2) 時間：查詢索引須要時間；

(3) 維護：索引需要維護（數據變動時）；

不建議使用索引的狀況：

(1) 數據量很小的表

(2) 空間緊張

經常使用優化總結

優化語句不少，須要注意的也不少，針對平時的狀況總結一下幾點：

一、有索引但未被用到的狀況（不建議）

(1) Like的參數以通配符開頭時

儘可能避免Like的參數以通配符開頭，不然數據庫引擎會放棄使用索引而進行全表掃描。

以通配符開頭的sql語句，例如：select * from t_credit_detail where Flistid like '%0'G

這是全表掃描，沒有使用到索引，不建議使用。

不以通配符開頭的sql語句，例如：select * from t_credit_detail where Flistid like '2%'G

很明顯，這使用到了索引，是有範圍的查找了，比以通配符開頭的sql語句效率提升很多。

(2) where條件不符合最左前綴原則時

例子已在最左前綴匹配原則的內容中有舉例。

(3) 使用！= 或 <> 操做符時

儘可能避免使用！= 或 <>操做符，不然數據庫引擎會放棄使用索引而進行全表掃描。使用>或<會比較高效。

select * from t_credit_detail where Flistid != '2000000608201108010831508721'G

(4) 索引列參與計算

應儘可能避免在 where 子句中對字段進行表達式操做，這將致使引擎放棄使用索引而進行全表掃描。

select * from t_credit_detail where Flistid +1 > '2000000608201108010831508722'G

(5) 對字段進行null值判斷

應儘可能避免在where子句中對字段進行null值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如： 低效：select * from t_credit_detail where Flistid is null ;

能夠在Flistid上設置默認值0，確保表中Flistid列沒有null值，而後這樣查詢： 高效：select * from t_credit_detail where Flistid =0;

(6) 使用or來鏈接條件

應儘可能避免在where子句中使用or來鏈接條件，不然將致使引擎放棄使用索引而進行全表掃描，如： 低效：select * from t_credit_detail where Flistid = '2000000608201108010831508721' or Flistid = '10000200001';

能夠用下面這樣的查詢代替上面的 or 查詢： 高效：select from t_credit_detail where Flistid = '2000000608201108010831508721' union all select from t_credit_detail where Flistid = '10000200001';

二、避免select *

在解析的過程當中，會將'*' 依次轉換成全部的列名，這個工做是經過查詢數據字典完成的，這意味着將耗費更多的時間。

因此，應該養成一個須要什麼就取什麼的好習慣。

三、order by 語句優化

任何在Order by語句的非索引項或者有計算表達式都將下降查詢速度。

方法：1.重寫order by語句以使用索引；

2.爲所使用的列創建另一個索引

  3.絕對避免在order by子句中使用表達式。

四、GROUP BY語句優化

提升GROUP BY 語句的效率, 能夠經過將不須要的記錄在GROUP BY 以前過濾掉

低效:

SELECT JOB , AVG(SAL)

FROM EMP

GROUP by JOB

HAVING JOB = ‘PRESIDENT'

OR JOB = ‘MANAGER'

高效:

SELECT JOB , AVG(SAL)

FROM EMP

WHERE JOB = ‘PRESIDENT'

OR JOB = ‘MANAGER'

GROUP by JOB

五、用 exists 代替 in

不少時候用 exists 代替 in 是一個好的選擇： select num from a where num in(select num from b) 用下面的語句替換： select num from a where exists(select 1 from b where num=a.num)

六、使用 varchar/nvarchar 代替 char/nchar

儘量的使用 varchar/nvarchar 代替 char/nchar ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。

七、能用DISTINCT的就不用GROUP BY

SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID

可改成：

SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10

八、能用UNION ALL就不要用UNION

UNION ALL不執行SELECT DISTINCT函數，這樣就會減小不少沒必要要的資源。

九、在Join表的時候使用至關類型的例，並將其索引

若是應用程序有不少JOIN 查詢，你應該確認兩個表中Join的字段是被建過索引的。這樣，MySQL內部會啓動爲你優化Join的SQL語句的機制。

並且，這些被用來Join的字段，應該是相同的類型的。例如：若是你要把 DECIMAL 字段和一個 INT 字段Join在一塊兒，MySQL就沒法使用它們的索引。對於那些STRING類型，還須要有相同的字符集才行。（兩個表的字符集有可能不同）

此文已由做者受權騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨，能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號