大家好，我是烤鴨：
????最近有點忙的頭暈，又懶又累，正好線上遇到慢sql的問題，就說下 MySQL Explain 關鍵字的解析和使用示例。

explain 關鍵字說明

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

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

id

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

select_type

select 查詢的類型，主要是用于區別普通查詢，聯合查詢，嵌套的復雜查詢
simple：簡單的select 查詢，查詢中不包含子查詢或者union
primary：查詢中若包含任何復雜的子查詢，最外層查詢則被標記為primary
subquery：在select或where 列表中包含了子查詢
dependent subquery: 子查詢中的第一個SELECT語句，依賴于外部查詢
uncacheable subquery: 對于該結果不能被緩存，必須重新評估外部查詢的每一行子查詢
derived：在from列表中包含的子查詢被標記為derived（衍生）MySQL會遞歸執行這些子查詢，把結果放在臨時表里。
union：若第二個select出現在union之后，則被標記為union，若union包含在from子句的子查詢中，外層select將被標記為：derived
dependent union: union 中的第二個或者后面的SELECT語句,依賴于外部查詢
uncacheable union: UNION中的第二個或者后面的SELECT語句屬于不可緩存子查詢 (see UNCACHEABLE SUBQUERY)
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

顯示索引的哪一列或常量被用于查找索引列上的值，常見的有：const（常量），func，NULL，字段名（例：film.id）。

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操作的循環次數。小表驅動大表，減輕連接的次數。

常用的參數：

select_type ：查詢類型

type：數據讀取操作的操作類型

key： 哪些索引被實際使用

ref：表之間的引用

rows： 每張表有多少行被優化器查詢

extra：額外的描述，比如額外的文件排序(多一次io)，使用索引，使用where條件等

線上問題sql

stage 和 video_source 是分別有索引的，但是按照這兩個條件執行耗時要幾秒…(一共不超過500w數據)

explain select count(1) from test_original where stage = 7 and video_source = 3;

看下執行計劃幾個常用參數：

type：index_merge

key：index_stage,index_video_source

rows：1042600

extra：Using intersect(index_stage,index_video_source); Using where; Using index

key和rows沒什么問題，這個type和extra比較有意思了。

index_merge指的是對多個索引分別進行條件掃描，然后將它們各自的結果進行合并

extra里的Using intersect(index_stage,index_video_source)指的就是求交集。

找到問題就知道怎么優化了。把兩個獨立索引改成聯合索引(避免兩次查詢后取交集)

type：ref

key：index_stage_video_source

rows：1042600

extra：Using index

可以看到建立聯合索引后，只是單獨的走了一次索引查詢，效率更高了。

組合索引

之前對組合索引有一點誤區，對最左匹配原則和組合索引的字段順序上，下面這段也是從別的博客copy來的，分享一下。

注意最左前綴，并不是是指：一定要按照各個字段出現在where中的順序來建立復合索引的。

比如 where status=2 and roleId=xxx and number = xxx

該條件建立符合索引，我們并不需要按照status,roleId，number它們出現的順序來建立索引：

alter table role_goods add index sin(status,roleId,number)

這是對最左前綴極大的誤解。因為 where status=2 and roleId=xxx and number = xxx 和 where roleId=xxx and number = xxx and status=2它們是等價的。復合索引，哪個字段放在最前面，需要根據哪個字段經常出現在where條件中，哪個字段的選擇性最好來判斷的。

就拿線上的那個sql來說，無論組合索引的順序怎么建立，下面這兩個是一樣的。

explain select count(1) from test_original where stage = 7 and video_source = 3; explain select count(1) from test_original where video_source = 3 and stage = 7;

但是 如果只查詢其中一個條件，又想走索引，就需要考慮順序了，只能是前面的可以走索引，這就是最左匹配。

三個字段的組合索引也一樣，不需要考慮順序，但是如果查詢1-2個索引，需要遵循最左匹配原則。

查詢 1 個索引的情況下，只能第一個索引生效。查詢 2個索引的情況下，包含第一個索引的都會生效(無論順序)。

總結

以上是生活随笔為你收集整理的从线上慢sql看explain关键字的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。