神奇的 SQL 之 MySQL 執行計劃 → EXPLAIN，讓我們了解 SQL 的執行程序！

前言

　　開心一刻

　　　　某人養了一頭豬，煩了想放生，可是豬認識回家的路，放生幾次它都自己回來了，一日，這個人想了個狠辦法，開車帶著豬轉了好多路進山區放生，放生后又各種打轉，然后掏出電話給家里人打了個電話，問道：“豬回去了嗎？”，家里人：“早回來了，你在哪了，怎么還沒回來？”，他大怒道：“讓它來接我，我特么迷路了！！！”

還不如我了

背景

　　某一天，樓主打完上班卡，坐在工位逛園子的時候，右下角的 QQ 閃了起來，而且還是個美女頭像！我又驚又喜，腦中閃過我所認識的可能聯系我的女性，得出個結論：她們這會不可能聯系我呀，影像也沒映象，到底是誰了？打開聊天視窗聊了起來

　　她：您好，我是公司客服某某某，請問 xxx后臺 是您負責的嗎？

　　我：您好，是我負責的，有什么問題嗎？

　　她：我發現 xxx 頁面點查詢后，一直是 加載中... ，資料一直出不來，能幫忙看看嗎？

　　我：是不是您的姿勢不對？

　　她：我就 xxx，然后點查詢

　　我：騷等下，我試試，確實有點慢，很長時間才能出來

　　她：是的，太慢了，出不來，都急死我了，能快點嗎？

　　我：肯定能、必須能！您覺得什么速度讓您覺得最舒服？

　　她：越快越好吧

　　我：呃...，是嗎，我先看看是什么問題，處理好了告訴您，保證讓您覺得舒服！

　　她：好的，謝謝！

　　公司沒有專門的搜索服務，都是直接從 MySQL 查詢，做簡單的資料處理后回傳給頁面，慢的原因肯定就是 SQL 查詢了，找到對應的查詢 SQL ，就是兩個表的聯表查詢，連接鍵也有索引，WHERE 條件也能走索引，怎么會慢了？然后我用 EXPLAIN 看了下這條 SQL 的執行計劃，找到了慢的原因，具體原因后面揭曉（誰讓你不是豬腳！）

EXPLAIN 是什么

　　它是 MySQL 的一個命令，用來查看 SQL 的執行計劃（SQL 如何執行），根據其輸出結果，我們能夠知道以下資訊：表的讀取順序，資料讀取型別，哪些索引可以使用，哪些索引實際使用了，表之間的連接型別，每張表有多少行被優化器查詢等資訊，根據這些資訊，我們可以找出 SQL 慢的原因，并做針對性的優化

　　MySQL 5.6 之前的版本，EXPLAIN 只能用于查看 SELECT 的執行計劃，而從 MySQL 5.6 開始，可以查看 SELECT 、 DELETE 、 INSERT 、 REPLACE 和 UPDATE 的執行計劃，這可不是我瞎掰，不信的可以去 MySQL 的官網查看：Understanding the Query Execution Plan

　　EXPLAIN 使用方式非常簡單，簡單的你都不敢相信，就是在我們常寫的 SELECT 、 DELETE 、 INSERT 、 REPLACE 和 UPDATE 陳述句之前加上 EXPLAIN 即可

EXPLAIN SELECT * FROM mysql.`user`;

EXPLAIN DELETE FROM t_user WHERE user_name = '123';

　　莫看 EXPLAIN 短，但它胖呀

雖然有點嬰兒肥，但也掩不住我逼人的帥氣！

　　雖然 EXPLAIN 使用起來非常簡單，但它的輸出結果中資訊量非常大，雖然我胖，但我肚中有貨呀！

環境和資料準備

　　MySQL 版本是 5.7.2 ，存盤引擎是 InnoDB 

-- 查看 MySQL 版本
SELECT VERSION();

-- MySQL 提供什么存盤引擎
SHOW ENGINES;

-- 查看默認存盤引擎
SHOW VARIABLES LIKE '%storage_engine%';

　　準備兩張表：用戶表 tbl_user 和用戶登錄記錄表 tbl_user_login_log ，并初始化部分部分資料

-- 表創建與資料初始化
DROP TABLE IF EXISTS tbl_user;
CREATE TABLE tbl_user (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  user_name VARCHAR(50) NOT NULL COMMENT '用戶名',
  sex TINYINT(1) NOT NULL COMMENT '性別, 1:男，0:女',
  create_time datetime NOT NULL COMMENT '創建時間',
  update_time datetime NOT NULL COMMENT '更新時間',
    remark VARCHAR(255) NOT NULL DEFAULT '' COMMENT '備注',
  PRIMARY KEY (id)
) COMMENT='用戶表';

DROP TABLE IF EXISTS tbl_user_login_log;
CREATE TABLE tbl_user_login_log (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  user_name VARCHAR(50) NOT NULL COMMENT '用戶名',
  ip VARCHAR(15) NOT NULL COMMENT '登錄IP',
  client TINYINT(1) NOT NULL COMMENT '登錄端, 1:android, 2:ios, 3:PC, 4:H5',
  create_time datetime NOT NULL COMMENT '創建時間',
  PRIMARY KEY (id)
) COMMENT='登錄日志';
INSERT INTO tbl_user(user_name,sex,create_time,update_time,remark) VALUES
('何天香',1,NOW(), NOW(),'朗眉星目，一表人材'),
('薛沉香',0,NOW(), NOW(),'天星樓的總樓主薛搖紅的女兒，也是天星樓的少總樓主，體態豐盈，烏發飄逸，指若春蔥，袖臂如玉，風姿卓然，高貴典雅，人稱“天星絕香”的武林第一大美女'),
('慕容蘭娟',0,NOW(), NOW(),'武林東南西北四大世家之北世家慕容長明的獨生女兒，生得玲瓏剔透，粉雕玉琢，脾氣卻是剛烈無比，又喜著火紅，所以人送綽號“火鳳凰”，是除天星樓薛沉香之外的武林第二大美女'),
('萇婷',0,NOW(), NOW(),'當今皇上最寵愛的侄女，北王府的郡主，腰肢纖細，遍體羅綺，眉若墨畫，唇點櫻紅；雖無沉香之雅重，蘭娟之熱烈，卻別現出一種空靈'),
('柳含姻',0,NOW(), NOW(),'武林四絕之一的添愁仙子董婉婉的徒弟，體態窈窕，姿容秀麗，真個是秋水為神玉為骨，芙蓉如面柳如腰，眉若墨畫，唇若點櫻，不弱西子半分，更勝玉環一籌; 搖紅樓、聽雨軒，琵琶一曲值千金!'),
('李凝雪',0,NOW(), NOW(),'李相國的女兒，神采奕奕，英姿颯爽，愛憎分明'),
('周遺夢',0,NOW(), NOW(),'音神傳人，湘妃竹琴的擁有者，云髻高盤，穿了一身黑色蟬翼紗衫，愈覺得冰肌玉骨，粉面櫻唇，格外嬌艷動人'),
('葉留痕',0,NOW(), NOW(),'圣域圣女，膚白如雪，白衣飄飄，宛如仙女一般，微笑中帶著說不出的柔和之美'),
('郭疏影',0,NOW(), NOW(),'揚灰右使的徒弟，秀發細眉，玉肌豐滑，嬌潤脫俗'),
('鐘鈞天',0,NOW(), NOW(),'天界，玄天九部 - 鈞天部的部主，超凡脫俗，仙氣逼人'),
('王雁云',0,NOW(), NOW(),'塵緣山莊二小姐，刁蠻任性'),
('許侍霜',0,NOW(), NOW(),'藥王谷谷主女兒，醫術高明'),
('馮黯凝',0,NOW(), NOW(),'桃花門門主，嬌艷如火，千嬌百媚');
INSERT INTO tbl_user_login_log(user_name, ip, client, create_time) VALUES
('薛沉香', '10.53.56.78',2, '2019-10-12 12:23:45'),
('萇婷', '10.53.56.78',2, '2019-10-12 22:23:45'),
('慕容蘭娟', '10.53.56.12',1, '2018-08-12 22:23:45'),
('何天香', '10.53.56.12',1, '2019-10-19 10:23:45'),
('柳含姻', '198.11.132.198',2, '2018-05-12 22:23:45'),
('馮黯凝', '198.11.132.198',2, '2018-11-11 22:23:45'),
('周遺夢', '198.11.132.198',2, '2019-06-18 22:23:45'),
('郭疏影', '220.181.38.148',3, '2019-10-21 09:45:56'),
('薛沉香', '220.181.38.148',3, '2019-10-26 22:23:45'),
('萇婷', '104.69.160.60',4, '2019-10-12 10:23:45'),
('王雁云', '104.69.160.61',4, '2019-10-16 20:23:45'),
('李凝雪', '104.69.160.62',4, '2019-10-17 20:23:45'),
('許侍霜', '104.69.160.63',4, '2019-10-18 20:23:45'),
('葉留痕', '104.69.160.64',4, '2019-10-19 20:23:45'),
('王雁云', '104.69.160.65',4, '2019-10-20 20:23:45'),
('葉留痕', '104.69.160.66',4, '2019-10-21 20:23:45');

SELECT * FROM tbl_user;
SELECT * FROM tbl_user_login_log;

EXPLAIN 輸出格式概覽

　　樓主再不講重點，估計有些看官老爺找他的 2 米長的大砍刀去了

　　這么滴，我們先來看看 EXPLAIN 輸出結果的大概，是不是長得滿臉麻子，讓我們望而生畏 ?

　　白白凈凈的，挺好，關鍵長啊！ 官方解釋如下

EXPLAIN 輸出格式詳解

　　EXPLAIN 的輸出欄位雖然有點多，但常關注的就那么幾個，但樓主秉著負責的態度，都給大家講一下，需要重點關注的欄位，樓主也會標明滴

　　EXPLAIN 支持的 SQL 陳述句有好幾種，但作業中用的最多的還是 SELECT ，所以樓主就偷個懶，以 SELECT 來講解 EXPLAIN，有興趣的老爺去試試其他的

　　id

　　　　輸出的是整數，用來標識整個 SQL 的執行順序，id 如果相同，從上往下依次執行；id不同，id 值越大，執行優先級越高，越先被執行；如果行參考其他行的并集結果，則該值可以為NULL

　　　　不重要，有所了解就好（其實非常簡單，看一遍基本就能記住了）

　　select_type

　　　　查詢的型別，官方說明如下

　　　　簡單幫大家翻譯一下（有能力的去讀官網，畢竟那是原配，最具權威性）

　　　　SIMPLE：簡單的 SELECT 查詢，沒有 UNION 或者子查詢，包括單表查詢或者多表 JOIN 查詢

　　　　PRIMARY： 最外層的 select 查詢，常見于子查詢或 UNION 查詢 ，最外層的查詢被標識為 PRIMARY

　　　　UNION：UNION 操作的第二個或之后的 SELECT，不依賴于外部查詢的結果集（外部查詢指的就是 PRIMARY 對應的 SELECT）

　　　　DEPENDENT UNION：UNION 操作的第二個或之后的 SELECT，依賴于外部查詢的結果集

　　　　UNION RESULT：UNION 的結果（如果是 UNION ALL 則無此結果）

　　　　SUBQUERY：子查詢中的第一個 SELECT 查詢，不依賴于外部查詢的結果集

　　　　DEPENDENT SUBQUERY：子查詢中的第一個select查詢，依賴于外部查詢的結果集

　　　　DERIVED：派生表（臨時表），常見于 FROM 子句中有子查詢的情況

　　　　　　注意：MySQL5.7 中對 Derived table 做了一個新特性，該特性允許將符合條件的 Derived table 中的子表與父查詢的表合并進行直接JOIN，從而簡化了執行計劃，同時也提高了執行效率；默認情況下，MySQL5.7 中這個特性是開啟的，所以默認情況下，上面的 SQL 的執行計劃應該是這樣的

　　　　　　可通過 SET SESSION optimizer_switch='derived_merge=on|off' 來開啟或關閉當前 SESSION 的該特性，貌似扯的有點遠了（樓主你是不是在隨性發揮？），更多詳情可以去查閱官網

　　　　MATERIALIZED：被物化的子查詢，MySQL5.6 引入的一種新的 select_type，主要是優化 FROM 或 IN 子句中的子查詢，更多詳情請查看：Optimizing Subqueries with Materialization

　　　　UNCACHEABLE SUBQUERY：對于外層的主表，子查詢不可被快取，每次都需要計算

　　　　UNCACHEABLE UNION：類似于 UNCACHEABLE SUBQUERY，只是出現在 UNION 操作中

　　　　SIMPLLE、PRIMARY、SUBQUERY、DERIVED 這 4 個在實際作業中碰到的會比較多，看得懂這 4 個就行了，至于其他的，碰到了再去查資料就好了（我也想全部記住，但用的少，太容易忘記了，我也很無賴呀）

　　table

　　　　顯示了對應行正在訪問哪個表(有別名就顯示別名)，還會有 <union2,3> 、 <subquery2> 、 <derived2> （這里的 2,3、2、2 指的是 id 列的值）類似的值，具體可以往上看，這里就不演示了（再演示就太長了，你們都看不下去了，那我不是白忙乎了 ?）

　　partitions

　　　　查詢進行匹配的磁區，對于非磁區表，該值為NULL，大多數情況下用不到磁區，所以這一列我們無需關注

　　type

　　　　關聯型別或者訪問型別，它指明了 MySQL 決定如何查找表中符合條件的行，這是我們判斷查詢是否高效的重要依據（type 之于 EXPLAIN，就好比三圍之于女人！），完整介紹請看：explain-join-types

　　　　其值有多種，我們以性能好到性能差的順序一個一個來看　　　　　

　　　　system

　　　　　　該表只有一行（=系統表），是 const 型別的特例
　　　　const

　　　　　　確定只有一行匹配的時候，mysql 優化器會在查詢前讀取它并且只讀取一次，速度非常快，用于 primary key 或 unique 索引中有常亮值比較的情形

　　　　eq_ref

　　　　　　對于每個來自于前面的表的行，從該表最多只回傳一條符合條件的記錄，當連接使用的索引是 PRIMARY KEY 或 UNIQUE NOT NULL 索引時使用，非常高效

　　　　ref

　　　　　　索引訪問，也稱索引查找，它回傳所有匹配某個單個值的行，此型別通常出現在多表的 JOIN 查詢, 針對于非 UNIQUE 或非 PRIMARY KEY, 或者是使用了最左前綴規則索引的查詢，換句話說，如果 JOIN 不能基于關鍵字選擇單個行的話，則使用ref

　　　　fulltext

　　　　　　當使用全文索引時會用到，這種索引一般用不到，會用專門的搜索服務(solr、elasticsearch等)來替代
　　　　ref_or_null

　　　　　　類似ref，但是添加了可以專門搜索 NULL 的行

　　　　　　這個是有前提條件的，前提為 weapon 列有索引，且 weapon 列存在  NULL 

　　　　index_merge

　　　　　　該訪問型別使用了索引合并優化方法

　　　　　　這個同樣也是有條件的， id 列和 weapon 列都有單列索引，如果出現 index_merge，并且這類 SQL 后期使用較頻繁，可以考慮把單列索引換為組合索引，這樣效率更高

　　　　unique_subquery

　　　　　　類似于兩表連接中被驅動表的 eq_ref 訪問方式，unique_subquery 是針對在一些包含 IN 子查詢的查詢陳述句中，如果查詢優化器決定將 IN 子查詢轉換為 EXISTS 子查詢，而且子查詢可以使用到主鍵或者唯一索引進行等值匹配時，則會使用 unique_subquery

　　　　index_subquery

　　　　　　index_subquery 與 unique_subquery類似，只不過訪問子查詢中的表時使用的是普通的索引

　　　　range

　　　　　　使用索引來檢索給定范圍的行，當使用 =、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 運算子，用常量比較關鍵字列時，則會使用 rang

　　　　　　前提是必須基于索引，也就是 id 上必須有索引

　　　　index

　　　　　　當我們可以使用索引覆寫，但需要掃描全部的索引記錄時，則會使用 index；進行統計時非常常見

　　　　ALL

　　　　　　我們熟悉的全表掃描

　　possible_keys

　　　　展示在這個 SQL 中，可能用到的索引有哪些，但不一定在查詢時使用，若為空則表示沒有可以使用的索引，此時可以通過檢查 WHERE 陳述句看是否可以參考某些列或者新建索引來提高性能

　　key

　　　　展示這個 SQL 實際使用的索引，如果沒有選擇索引，則此列為null，要想強制 MySQL 使用或忽視 possible_keys 列中的索引，在查詢中使用 FORCE INDEX、USE INDEX 或者I GNORE INDEX

　　key_len

　　　　展示 MySQL 決定使用的鍵長度（位元組數），如果 key 是 NULL，則長度為 NULL，在不損失精確性的情況下，長度越短越好

　　ref

　　　　展示的是與索引列作等值匹配的東東是個啥，比如只是一個常數或者是某個列，它顯示的列的名字（或const），此列多數時候為 Null

　　rows

　　　　展示的是 mysql 決議器認為執行此 SQL 時預計需要掃描的行數，此數值為一個預估值，不是具體值，通常比實際值小

　　filtered

　　　　展示的是被條件過濾的行數所占需要讀到的行（rows 的值）的比例（省略了百分號，顯示的是百分號前的值）；我們平時關注的不多，有興趣的可以去仔細琢磨下，你會有更多發現

　　extra

　　　　表示不在其他列但也很重要的額外資訊，取值有很多，我們挑一些比較常見的過一下

　　　　using index

　　　　　　表示 SQL 使用了使用覆寫索引，而不用回表去查詢資料，性能非常不錯

　　　　using where

　　　　　　表示存盤引擎搜到記錄后進行了后過濾(POST-FILTER)，如果查詢未能使用索引，using where 的作用只是提醒我們 mysql 要用 where 條件過濾結果集

　　　　using temporary

　　　　　　表示 mysql 需要使用臨時表來存盤結果集，常見于排序和分組查詢

　　　　using filesort

　　　　　　表示 mysql 無法利用索引直接完成排序（排序的欄位不是索引欄位），此時會用到緩沖空間（記憶體或者磁盤）來進行排序；一般出現該值，則表示 SQL 要進行優化了，它對 CPU 的消耗是比較大的

　　　　impossible where

　　　　　　查詢陳述句的WHERE子句永遠為 FALSE 時將會提示該額外資訊

 　　　　當然還有其他的，不常見，等碰到了大家再去查吧（現在凌晨 1 點，我實在是太困了！）

總結

　　1、背景疑問

　　　　還記得客服小姐姐的問題嗎，她嫌我們太慢，具體原因下篇再詳細介紹，這里簡單提一下：連表查詢的 連接鍵 型別不一致，一個 INT 型別，一個 VARCHAR 型別，導致 type 是 ALL（這誰設計的呀，坑死人呀！ 難道是我 ？）

　　2、思維導圖

　　　　本來是想自己畫個思維導圖的，可上網一搜，發現了一個人家畫好了的思維導圖，我就偷個懶借用下：MySQL優化正餐之_EXPLAIN執行計劃，里面描述的很詳細，同時也包括了各種示例，真香！

　　3、肚中精華

　　　　EXPLAIN 的輸出內容很多，我們沒必要全部掌握，重點我已經幫大家劃好

　　　　type，就像 RMB 一樣重要

　　　　key，也像 RMB 一樣重要

　　　　extra，還像 RMB 一樣重要

　　　　說白了還是 RMB 最重要，不是，我的意思是 type、key、extra 都很重要，其他的用到了再去買吧

　　4、示例代碼

　　　　快點我

標籤：MySQL

上一篇：在cnetos7上搭建mysql主從服務

下一篇：手把手教你，如何在windows系統搭建mysql主從復制的環境