淺談MySQL索引優化分析

阿新 • • 發佈：2020-01-09

為什麼你寫的sql查詢慢？為什麼你建的索引常失效？通過本章內容，你將學會MySQL效能下降的原因，索引的簡介，索引建立的原則，explain命令的使用，以及explain輸出欄位的意義。助你瞭解索引，分析索引，使用索引，從而寫出更高效能的sql語句。還在等啥子？擼起袖子就是幹！

案例分析

我們先簡單瞭解一下非關係型資料庫和關係型資料庫的區別。

MongoDB是NoSQL中的一種。NoSQL的全稱是Not only SQL，非關係型資料庫。它的特點是效能高，擴張性強，模式靈活，在高併發場景表現得尤為突出。但目前它還只是關係型資料庫的補充，它在資料的一致性，資料的安全性，查詢的複雜性問題上和關係型資料庫還存在一定差距。

MySQL是關係性資料庫中的一種，查詢功能強，資料一致性高，資料安全性高，支援二級索引。但效能方面稍遜與MongoDB，特別是百萬級別以上的資料，很容易出現查詢慢的現象。這時候需要分析查詢慢的原因，一般情況下是程式設計師sql寫的爛，或者是沒有鍵索引，或者是索引失效等原因導致的。

公司ERP系統資料庫主要是MongoDB（最接近關係型資料的NoSQL），其次是Redis，MySQL只佔很少的部分。現在又重新使用MySQL，歸功於阿里巴巴的奇門系統和聚石塔系統。考慮到訂單數量已經是百萬級以上，對MySQL的效能分析也就顯得格外重要。

我們先通過兩個簡單的例子來入門。後面會詳細介紹各個引數的作用和意義。

說明：需要用到的sql已經放在了github上了，喜歡的同學可以點一下star，哈哈。

https://github.com/ITDragonBlog/daydayup/tree/master/MySQL/

場景一：訂單匯入，通過交易號避免重複導單

業務邏輯：訂單匯入時，為了避免重複導單，一般會通過交易號去資料庫中查詢，判斷該訂單是否已經存在。

最基礎的sql語句

mysql> select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
+-------+--------------------+-------+------+----------+--------------+----------+------------------+-------------+-------------+------------+---------------------+
| id  | transaction_id   | gross | net | stock_id | order_status | descript | finance_descript | create_type | order_level | input_user | input_date     |
+-------+--------------------+-------+------+----------+--------------+----------+------------------+-------------+-------------+------------+---------------------+
| 10000 | 81X97310V32236260E |  6.6 | 6.13 |    1 |      10 | ok    | ok        | auto    |      1 | itdragon  | 2017-08-18 17:01:49 |
+-------+--------------------+-------+------+----------+--------------+----------+------------------+-------------+-------------+------------+---------------------+

mysql> explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table        | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra    |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | ALL | NULL     | NULL | NULL  | NULL |  3 |  33.33 | Using where |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+-------------+

查詢的本身沒有任何問題，線上下的測試環境也沒有任何問題。可是，功能一旦上線，查詢慢的問題就迎面而來。幾百上千萬的訂單，用全表掃描？啊？哼!

怎麼知道該sql是全表掃描呢？通過explain命令可以清楚MySQL是如何處理sql語句的。列印的內容分別表示：

id : 查詢序列號為1。
select_type : 查詢型別是簡單查詢，簡單的select語句沒有union和子查詢。
table : 表是 itdragon_order_list。
partitions : 沒有分割槽。
type : 連線型別，all表示採用全表掃描的方式。
possible_keys : 可能用到索引為null。
key : 實際用到索引是null。
key_len : 索引長度當然也是null。
ref : 沒有哪個列或者引數和key一起被使用。
Extra : 使用了where查詢。

因為資料庫中只有三條資料，所以rows和filtered的資訊作用不大。這裡需要重點了解的是type為ALL，全表掃描的效能是最差的，假設資料庫中有幾百萬條資料，在沒有索引的幫助下會異常卡頓。

初步優化：為transaction_id建立索引

mysql> create unique index idx_order_transaID on itdragon_order_list (transaction_id);
mysql> explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------+
| id | select_type | table        | partitions | type | possible_keys   | key        | key_len | ref  | rows | filtered | Extra |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | const | idx_order_transaID | idx_order_transaID | 453   | const |  1 |   100 | NULL |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------+

這裡建立的索引是唯一索引，而非普通索引。

唯一索引列印的type值是const。表示通過索引一次就可以找到。即找到值就結束掃描返回查詢結果。

普通索引列印的type值是ref。表示非唯一性索引掃描。找到值還要繼續掃描，直到將索引檔案掃描完為止。(這裡沒有貼出程式碼)
顯而易見，const的效能要遠高於ref。並且根據業務邏輯來判斷，建立唯一索引是合情合理的。

再次優化：覆蓋索引

mysql> explain select transaction_id from itdragon_order_list where transaction_id = "81X97310V32236260E";
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------------+
| id | select_type | table        | partitions | type | possible_keys   | key        | key_len | ref  | rows | filtered | Extra    |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | const | idx_order_transaID | idx_order_transaID | 453   | const |  1 |   100 | Using index |
+----+-------------+---------------------+------------+-------+--------------------+--------------------+---------+-------+------+----------+-------------+

這裡將select * from 改為了 select transaction_id from 後 Extra 顯示 Using index，表示該查詢使用了覆蓋索引，這是一個非常好的訊息，說明該sql語句的效能很好。若提示的是Using filesort(使用內部排序)和Using temporary(使用臨時表)則表明該sql需要立即優化了。

根據業務邏輯來的，查詢結構返回transaction_id 是可以滿足業務邏輯要求的。

場景二，訂單管理頁面，通過訂單級別和訂單錄入時間排序

業務邏輯：優先處理訂單級別高，錄入時間長的訂單。
既然是排序，首先想到的應該是order by，還有一個可怕的 Using filesort 等著你。

最基礎的sql語句

mysql> explain select * from itdragon_order_list order by order_level,input_date;
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table        | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra     |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | ALL | NULL     | NULL | NULL  | NULL |  3 |   100 | Using filesort |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+

首先，採用全表掃描就不合理，還使用了檔案排序Using filesort，更加拖慢了效能。

MySQL在4.1版本之前檔案排序是採用雙路排序的演算法，由於兩次掃描磁碟，I/O耗時太長。後優化成單路排序演算法。其本質就是用空間換時間，但如果資料量太大，buffer的空間不足，會導致多次I/O的情況。其效果反而更差。與其找運維同事修改MySQL配置，還不如自己乖乖地建索引。

初步優化：為order_level,input_date 建立複合索引

mysql> create index idx_order_levelDate on itdragon_order_list (order_level,input_date);
mysql> explain select * from itdragon_order_list order by order_level,input_date;
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table        | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra     |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | ALL | NULL     | NULL | NULL  | NULL |  3 |   100 | Using filesort |
+----+-------------+---------------------+------------+------+---------------+------+---------+------+------+----------+----------------+

建立複合索引後你會驚奇的發現，和沒建立索引一樣？？？都是全表掃描，都用到了檔案排序。是索引失效？還是索引建立失敗？我們試著看看下面列印情況

mysql> explain select order_level,input_date from itdragon_order_list order by order_level,input_date;
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------------+
| id | select_type | table        | partitions | type | possible_keys | key         | key_len | ref | rows | filtered | Extra    |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | index | NULL     | idx_order_levelDate | 68   | NULL |  3 |   100 | Using index |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------------+

將select * from 換成了 select order_level,input_date from 後。type從all升級為index，表示（full index scan）全索引檔案掃描，Extra也顯示使用了覆蓋索引。可是不對啊！！！！檢索雖然快了，但返回的內容只有order_level和input_date 兩個欄位，讓業務同事怎麼用？難道把每個欄位都建一個複合索引？

MySQL沒有這麼笨，可以使用force index 強制指定索引。在原來的sql語句上修改 force index(idx_order_levelDate) 即可。

mysql> explain select * from itdragon_order_list force index(idx_order_levelDate) order by order_level,input_date;
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------+
| id | select_type | table        | partitions | type | possible_keys | key         | key_len | ref | rows | filtered | Extra |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | index | NULL     | idx_order_levelDate | 68   | NULL |  3 |   100 | NULL |
+----+-------------+---------------------+------------+-------+---------------+---------------------+---------+------+------+----------+-------+

再次優化：訂單級別真的要排序麼？

其實給訂單級別排序意義並不大，給訂單級別新增索引意義也不大。因為order_level的值可能只有，低，中，高，加急，這四種。對於這種重複且分佈平均的欄位，排序和加索引的作用不大。

我們能否先固定 order_level 的值，然後再給 input_date 排序？如果查詢效果明顯，是可以推薦業務同事使用該查詢方式。

mysql> explain select * from itdragon_order_list where order_level=3 order by input_date;
+----+-------------+---------------------+------------+------+---------------------+---------------------+---------+-------+------+----------+-----------------------+
| id | select_type | table        | partitions | type | possible_keys    | key         | key_len | ref  | rows | filtered | Extra         |
+----+-------------+---------------------+------------+------+---------------------+---------------------+---------+-------+------+----------+-----------------------+
| 1 | SIMPLE   | itdragon_order_list | NULL    | ref | idx_order_levelDate | idx_order_levelDate | 5    | const |  1 |   100 | Using index condition |
+----+-------------+---------------------+------------+------+---------------------+---------------------+---------+-------+------+----------+-----------------------+

和之前的sql比起來，type從index 升級為 ref(非唯一性索引掃描)。索引的長度從68變成了5，說明只用了一個索引。ref也是一個常量。Extra 為Using index condition 表示自動根據臨界值，選擇索引掃描還是全表掃描。總的來說效能遠勝於之前的sql。

上面兩個案例只是快速入門，我們需嚴記一點：優化是基於業務邏輯來的。絕對不能為了優化而擅自修改業務邏輯。如果能修改當然是最好的。

索引簡介

官方定義：索引（Index）是幫助MySQL高效獲取資料的資料結構。

大家一定很好奇，索引為什麼是一種資料結構，它又是怎麼提高查詢的速度？我們拿最常用的二叉樹來分析索引的工作原理。

看下面的圖片：

建立索引的優勢

1 提高資料的檢索速度，降低資料庫IO成本：使用索引的意義就是通過縮小表中需要查詢的記錄的數目從而加快搜索的速度。

2 降低資料排序的成本，降低CPU消耗：索引之所以查的快，是因為先將資料排好序，若該欄位正好需要排序，則真好降低了排序的成本。

建立索引的劣勢

1 佔用儲存空間：索引實際上也是一張表，記錄了主鍵與索引欄位，一般以索引檔案的形式儲存在磁碟上。

2 降低更新表的速度：表的資料發生了變化，對應的索引也需要一起變更，從而減低的更新速度。否則索引指向的物理資料可能不對，這也是索引失效的原因之一。

3 優質索引建立難：索引的建立並非一日之功，也並非一直不變。需要頻繁根據使用者的行為和具體的業務邏輯去建立最佳的索引。

索引分類

我們常說的索引一般指的是BTree（多路搜尋樹）結構組織的索引。其中還有聚合索引，次要索引，複合索引，字首索引，唯一索引，統稱索引，當然除了B+樹外，還有雜湊索引（hash index）等。

單值索引：一個索引只包含單個列，一個表可以有多個單列索引
唯一索引：索引列的值必須唯一，但允許有空值
複合索引：一個索引包含多個列，實際開發中推薦使用

實際開發中推薦使用複合索引，並且單表建立的索引個數建議不要超過五個

基本語法：

建立：

create [unique] index indexName on tableName (columnName...)
alter tableName add [unique] index [indexName] on (columnName...)

刪除：

drop index [indexName] on tableName

檢視：

show index from tableName

哪些情況需要建索引：

1 主鍵，唯一索引
2 經常用作查詢條件的欄位需要建立索引
3 經常需要排序、分組和統計的欄位需要建立索引
4 查詢中與其他表關聯的欄位，外來鍵關係建立索引

哪些情況不要建索引：

1 表的記錄太少，百萬級以下的資料不需要建立索引
2 經常增刪改的表不需要建立索引
3 資料重複且分佈平均的欄位不需要建立索引，如 true,false 之類。
4 頻發更新的欄位不適合建立索引
5 where條件裡用不到的欄位不需要建立索引

效能分析

MySQL 自身瓶頸

MySQL自身參見的效能問題有磁碟空間不足，磁碟I/O太大，伺服器硬體效能低。
1 CPU：CPU 在飽和的時候一般發生在資料裝入記憶體或從磁碟上讀取資料時候
2 IO：磁碟I/O 瓶頸發生在裝入資料遠大於記憶體容量的時候
3 伺服器硬體的效能瓶頸：top,free,iostat 和 vmstat來檢視系統的效能狀態

explain 分析sql語句

使用explain關鍵字可以模擬優化器執行sql查詢語句，從而得知MySQL 是如何處理sql語句。

+----+-------------+-------+------------+------+---------------+-----+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-----+---------+------+------+----------+-------+

select 查詢的序列號，包含一組可以重複的數字，表示查詢中執行sql語句的順序。一般有三種情況：
第一種：id全部相同，sql的執行順序是由上至下；
第二種：id全部不同，sql的執行順序是根據id大的優先執行；
第三種：id既存在相同，又存在不同的。先根據id大的優先執行，再根據相同id從上至下的執行。

select_type

select 查詢的型別，主要是用於區別普通查詢，聯合查詢，巢狀的複雜查詢
simple：簡單的select 查詢，查詢中不包含子查詢或者union
primary：查詢中若包含任何複雜的子查詢，最外層查詢則被標記為primary
subquery：在select或where 列表中包含了子查詢
derived：在from列表中包含的子查詢被標記為derived（衍生）MySQL會遞迴執行這些子查詢，把結果放在臨時表裡。
union：若第二個select出現在union之後，則被標記為union，若union包含在from子句的子查詢中，外層select將被標記為：derived
union result：從union表獲取結果的select

partitions

表所使用的分割槽，如果要統計十年公司訂單的金額，可以把資料分為十個區，每一年代表一個區。這樣可以大大的提高查詢效率。

type

這是一個非常重要的引數，連線型別，常見的有：all,index,range,ref,eq_ref,const,system,null 八個級別。
效能從最優到最差的排序：system > const > eq_ref > ref > range > index > all
對java程式設計師來說，若保證查詢至少達到range級別或者最好能達到ref則算是一個優秀而又負責的程式設計師。
all：（full table scan）全表掃描無疑是最差，若是百萬千萬級資料量，全表掃描會非常慢。
index：（full index scan）全索引檔案掃描比all好很多，畢竟從索引樹中找資料，比從全表中找資料要快。
range：只檢索給定範圍的行，使用索引來匹配行。範圍縮小了，當然比全表掃描和全索引檔案掃描要快。sql語句中一般會有between，in，>，< 等查詢。
ref：非唯一性索引掃描，本質上也是一種索引訪問，返回所有匹配某個單獨值的行。比如查詢公司所有屬於研發團隊的同事，匹配的結果是多個並非唯一值。
eq_ref：唯一性索引掃描，對於每個索引鍵，表中有一條記錄與之匹配。比如查詢公司的CEO，匹配的結果只可能是一條記錄，
const：表示通過索引一次就可以找到，const用於比較primary key 或者unique索引。因為只匹配一行資料，所以很快，若將主鍵至於where列表中，MySQL就能將該查詢轉換為一個常量。
system：表只有一條記錄（等於系統表），這是const型別的特列，平時不會出現，瞭解即可

possible_keys

顯示查詢語句可能用到的索引(一個或多個或為null)，不一定被查詢實際使用。僅供參考使用。

key

顯示查詢語句實際使用的索引。若為null，則表示沒有使用索引。

key_len

顯示索引中使用的位元組數，可通過key_len計算查詢中使用的索引長度。在不損失精確性的情況下索引長度越短越好。key_len 顯示的值為索引欄位的最可能長度，並非實際使用長度，即key_len是根據表定義計算而得，並不是通過表內檢索出的。

ref

顯示索引的哪一列或常量被用於查詢索引列上的值。

rows

根據表統計資訊及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數，值越大越不好。

extra

Using filesort：說明MySQL會對資料使用一個外部的索引排序，而不是按照表內的索引順序進行讀取。MySQL中無法利用索引完成的排序操作稱為“檔案排序” 。出現這個就要立刻優化sql。
Using temporary：使用了臨時表儲存中間結果，MySQL在對查詢結果排序時使用臨時表。常見於排序 order by 和分組查詢 group by。出現這個更要立刻優化sql。
Using index：表示相應的select 操作中使用了覆蓋索引（Covering index），避免訪問了表的資料行，效果不錯！如果同時出現Using where，表明索引被用來執行索引鍵值的查詢。如果沒有同時出現Using where，表示索引用來讀取資料而非執行查詢動作。
覆蓋索引（Covering Index）：也叫索引覆蓋，就是select 的資料列只用從索引中就能夠取得，不必讀取資料行，MySQL可以利用索引返回select 列表中的欄位，而不必根據索引再次讀取資料檔案。
Using index condition：在5.6版本後加入的新特性，優化器會在索引存在的情況下，通過符合RANGE範圍的條數和總數的比例來選擇是使用索引還是進行全表遍歷。
Using where：表明使用了where 過濾
Using join buffer：表明使用了連線快取
impossible where： where 語句的值總是false，不可用，不能用來獲取任何元素
distinct：優化distinct操作，在找到第一匹配的元組後即停止找同樣值的動作。

filtered

一個百分比的值，和rows 列的值一起使用，可以估計出查詢執行計劃(QEP)中的前一個表的結果集，從而確定join操作的迴圈次數。小表驅動大表，減輕連線的次數。

通過explain的引數介紹，我們可以得知:
1 表的讀取順序(id)
2 資料讀取操作的操作型別(type)
3 哪些索引被實際使用(key)
4 表之間的引用(ref)
5 每張表有多少行被優化器查詢(rows)

效能下降的原因

從程式設計師的角度
1 查詢語句寫的不好
2 沒建索引，索引建的不合理或索引失效
3 關聯查詢有太多的join

從伺服器的角度
1 伺服器磁碟空間不足
2 伺服器調優配置引數設定不合理

總結

1 索引是排好序且快速查詢的資料結構。其目的是為了提高查詢的效率。
2 建立索引後，查詢資料變快，但更新資料變慢。
3 效能下降的原因很可能是索引失效導致。
4 索引建立的原則，經常查詢的欄位適合建立索引，頻繁需要更新的資料不適合建立索引。
5 索引欄位頻繁更新，或者表資料物理刪除容易造成索引失效。
6 擅用 explain 分析sql語句
7 除了優化sql語句外，還可以優化表的設計。如儘量做成單表查詢，減少表之間的關聯。設計歸檔表等。

到這裡，MySQL的索引優化分析就結束了，有什麼不對的地方，大家可以提出來。如果覺得不錯可以點一下推薦。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。

淺談MySQL索引優化分析

淺談MySQL索引優化分析

淺談MySQL的B樹索引與索引優化小結

淺談mysql使用limit分頁優化方案的實現

淺談MySQL大表優化方案

第三節：MySQL索引優化規則套路實戰1(索引分析、索引失效、查詢優化)

淺談MySQL（一）：儲存引擎與索引

手把手教你MySQL查詢優化分析

淺談關於SQL優化的思路

一步步教你MySQL查詢優化分析教程

淺談MySQL分頁Limit的效能問題

淺談MySQL中四種常用儲存引擎

淺談Mysql、SqlServer、Oracle三大資料庫的區別

淺談mysql 系統使用者最大檔案開啟數限制

淺談MySQL和MariaDB區別(mariadb和mysql的效能比較)

淺談Mysql指定順序排序查詢

淺談mysql的子查詢聯合與in的效率

淺談資料庫索引的作用及原理

MySQL-索引優化案例

淺談C++ 虛擬函式分析

淺談MySql 檢視、觸發器以及儲存過程

淺談MySQL索引優化分析

相關推薦