MySQL 執行計划詳解

參考資源：https://www.cnblogs.com/yinjw/p/11864477.html

我們經常使用 MySQL 的執行計划來查看 SQL 語句的執行效率，接下來分析執行計划的各個顯示內容。

另附一篇 MS SQLSERVER查詢優化器文章：https://www.cnblogs.com/fish-li/archive/2011/06/06/2073626.html

• 執行計划的 id

select 查詢的序列號，標識執行的順序

• id 相同，執行順序由上至下
• id 不同，如果是子查詢，id 的序號會遞增，id 值越大優先級越高，越先被執行

 

先看id 相同，執行順序由上至下(本質是先查找表數據量小的表)

普通的關聯查詢，先查詢執行數據量小的表（執行計划的ID相同）：

 

 

 

 

 

• id 不同，如果是子查詢，id 的序號會遞增，id 值越大優先級越高，越先被執行

子查詢語句，先執行最內層語句，一層層向外執行查詢，看下面的執行計划（執行計划的ID不同）

先查詢c表，再執行t表，最后執行tc表

 

 

 

 

• 執行計划的 select_type

 

 

查詢的類型，主要是用於區分普通查詢、聯合查詢、子查詢等。

• SIMPLE：簡單的 select 查詢，查詢中不包含子查詢或者 union
• PRIMARY：查詢中包含子部分，最外層查詢則被標記為 primary
• DERIVED：衍生查詢（用到了臨時表）
• SUBQUERY/MATERIALIZED：SUBQUERY 表示在 select 或 where 列表中包含了子查詢，MATERIALIZED：表示 where 后面 in 條件的子查詢
• UNION：表示 union 中的第二個或后面的 select 語句
• UNION RESULT：union 的結果

對於 UNION 和 UNION RESULT 可以通過下面的例子展現：

EXPLAIN
SELECT * FROM users WHERE id IN(1, 2)
UNION
SELECT * FROM users WHERE id IN(3, 4);

 

只有一個子查詢的衍生select_type查詢類型

 

 

 

子查詢中用了union的衍生查詢

 

 

 

 

 

 

• 執行計划的 table

查詢涉及到的表。

• 直接顯示表名或者表的別名
• <unionM,N> 由 ID 為 M，N 查詢 union 產生的結果
• <subqueryN> 由 ID 為 N 查詢產生的結果

 

• 執行計划的 type （索引類型）

訪問類型，SQL 查詢優化中一個很重要的指標，結果值從好到壞依次是(性能由高到低)：system > const > eq_ref > ref > range > index > ALL

• system：系統表，少量數據，往往不需要進行磁盤IO（理想情況，很少達到）
• const：常量連接，只能查到1數據，用於主鍵或者唯一索引（理想情況，很少達到）
• eq_ref：主鍵索引（primary key）或者非空唯一索引（unique not null）等值掃描（理想情況，很少達到）
• ref：非主鍵非唯一索引等值掃描（優化后一般達到這個級別，前提是有索引）
• range：范圍掃描（優化后一般達到這個級別，前提是有索引）
• index：索引樹掃描（全索引掃描）[速度比all快]
• ALL：全表數據掃描（full table scan）[不是索引就會全表數據掃描]

　　

 

 

 

下面通過舉例說明。

system

explain select * from mysql.time_zone;

上例中，從系統庫 MySQL 的系統表 time_zone 里查詢數據，訪問類型為 system，這些數據已經加載到內存里，不需要進行磁盤 IO，這類掃描是速度最快的。

explain select * from (select * from user where id=1) tmp;

再舉一個例子，內層嵌套（const）返回了一個臨時表，外層嵌套從臨時表查詢，其掃描類型也是 system，也不需要走磁盤 IO，速度超快。

const 

數據准備：

CREATE TABLE `user` (
  `id` int(11) NOT NULL,
  `NAME` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user values(1,'shenjian');
insert into user values(2,'zhangsan');
insert into user values(3,'lisi');

explain select * from user where id=1;

const 掃描的條件為： 

1. 命中主鍵（primary key）或者唯一（unique）索引
2. 被連接的部分是一個常量（const）值 

如上例，id 是 主鍵索引，連接部分是常量1。

eq_ref

數據准備：

CREATE TABLE `user` (
  `id` int(11) NOT NULL,
  `NAME` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user values(1,'shenjian');
insert into user values(2,'zhangsan');
insert into user values(3,'lisi');

CREATE TABLE `user_ex` (
  `id` int(11) NOT NULL,
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user_ex values(1,18);
insert into user_ex values(2,20);
insert into user_ex values(3,30);
insert into user_ex values(4,40);
insert into user_ex values(5,50);

EXPLAIN SELECT * FROM USER,user_ex WHERE user.id=user_ex.id;

eq_ref 掃描的條件為，對於前表的每一行（row），后表只有一行被掃描。 

再細化一點：  

1. join 查詢
2. 命中主鍵（primary key）或者非空唯一（unique not null）索引
3. 等值連接；

如上例，id 是主鍵，該 join 查詢為 eq_ref 掃描。

ref

數據准備：

CREATE TABLE `user` (
  `id` int(11) DEFAULT NULL,
  `name` varchar(20) DEFAULT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user values(1,'shenjian');
insert into user values(2,'zhangsan');
insert into user values(3,'lisi');

CREATE TABLE `user_ex` (
  `id` int(11) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user_ex values(1,18);
insert into user_ex values(2,20);
insert into user_ex values(3,30);
insert into user_ex values(4,40);
insert into user_ex values(5,50);

EXPLAIN SELECT * FROM USER,user_ex WHERE user.id=user_ex.id;

如果把上例 eq_ref 案例中的主鍵索引，改為普通非唯一（non unique）索引。就由 eq_ref 降級為了 ref，此時對於前表的每一行（row），后表可能有多於一行的數據被掃描。

select * from user where id=1;

當 id 改為普通非唯一索引后，常量的連接查詢，也由 const 降級為了 ref，因為也可能有多於一行的數據被掃描。

ref 掃描，可能出現在 join 里，也可能出現在單表普通索引里，每一次匹配可能有多行數據返回，雖然它比 eq_ref 要慢，但它仍然是一個很快的 join 類型。

range

數據准備：

CREATE TABLE `user` (
  `id` int(11) NOT NULL,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user values(1,'shenjian');
insert into user values(2,'zhangsan');
insert into user values(3,'lisi');
insert into user values(4,'wangwu');
insert into user values(5,'zhaoliu');

explain select * from user where id between 1 and 4;
explain select * from user where id in(1,2,3);
explain select * from user where id > 3;

range 掃描就比較好理解了，它是索引上的范圍查詢，它會在索引上掃碼特定范圍內的值。

像上例中的 between，in，>，<，>= 都是典型的范圍（range）查詢（in有時候會失效，也就是ALL，查詢所有【此時不會通過索引查詢】）

index

explain count (*) from user;

如上例，id 是主鍵，該 count 查詢需要通過掃描索引上的全部數據來計數，它僅比全表掃描快一點。

ALL 

數據准備：

CREATE TABLE `user` (
  `id` int(11) DEFAULT NULL,
  `name` varchar(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user values(1,'shenjian');
insert into user values(2,'zhangsan');
insert into user values(3,'lisi');

CREATE TABLE `user_ex` (
  `id` int(11) DEFAULT NULL,
  `age` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into user_ex values(1,18);
insert into user_ex values(2,20);
insert into user_ex values(3,30);
insert into user_ex values(4,40);
insert into user_ex values(5,50);

explain select * from user,user_ex where user.id=user_ex.id;

如果 id 上不建索引，對於前表的每一行（row），后表都要被全表掃描。

文章中，這個相同的 join 語句出現了三次：

1. 掃描類型為 eq_ref，此時 id 為主鍵
2. 掃描類型為 ref，此時 id 為非唯一普通索引
3. 掃描類型為 ALL，全表掃描，此時id上無索引

有此可見，建立正確的索引，對數據庫性能的提升是多么重要。

總結 

1. explain 結果中的 type 字段，表示（廣義）連接類型，它描述了找到所需數據使用的掃描方式；
2. 常見的掃描類型有：system>const>eq_ref>ref>range>index>ALL，其掃描速度由快到慢；
3. 各類掃描類型的要點是：

1. system 最快：不進行磁盤 IO
2. const：PK 或者 unique 上的等值查詢
3. eq_ref：PK 或者 unique 上的 join 查詢，等值匹配，對於前表的每一行，后表只有一行命中
4. ref：非唯一索引，等值匹配，可能有多行命中
5. range：索引上的范圍掃描，例如：between、in、>
6. index：索引上的全集掃描，例如：InnoDB 的 count
7. ALL 最慢：全表掃描

4. 建立正確的索引，非常重要；
5. 使用 explain 了解並優化執行計划，非常重要；

 

• 執行計划 possible_keys

　　查詢過程中有可能用到的索引，是一種預測，不准。

　　

 

 

 

• 執行計划 key

　　實際使用的索引，如果為 NULL ，則沒有使用索引。

　　

 

 

• key_lens　　

　　相關視頻資源見（課程：51CTO 《SQL優化(MySQL版)》10索引類型及逐步優化、key_len計算方法）

　　

 

 

 

　　 

　　

 

 

　　

 

　　 

• 復合索引

　　的意思：先根據第一個字段查比如“張三”，如果通過第一個字段的索引查到了有“張三”，就不用再查第二個字段了，否則需要查第二個字段的索引。

 　　

 

 上面創建了一個復合索引

 

以下執行explain select * from test_k1 where name1='';

索引長度為121（查找name1會使用復合索引，但先會查找name【查找了2個字段的索引】，再去查找name1所以索引長度為121）

name1字段可以為空，索引為用1個字節標示一下是否為空，所以為121

 

而執行搜索name這個語句，直接用name過些查到了，而且name字段不可以為空，索引的長度為60

 

 

 

•  執行計划ref

• const代表常量、其他值代碼引用的表

　　

 

 

　　首先2列其中一列沒有索引ref為null

　　

 

　　加完索引再看（我們研究索引，所以必須加索引）

 

 

 

 

 

• 執行計划 rows

　　根據表統計信息或者索引選用情況，大致估算出找到所需的記錄所需要讀取的行數。

　　

 

 

 

• 執行計划 filtered 

　　表示返回結果的行數占需讀取行數的百分比， filtered 的值越大越好。

• 執行計划 Extra 

　　十分重要的額外信息。

• Using filesort：MySQL 對數據使用一個額外的排序，而不是按照表內的索引進行排序讀取(性能消耗太大)【如果是復合索引，where和order by要按照過些順序寫，不然也會Using filesort，比如where c1=1 order by c3中間跨了c2】
• Using temporary：使用臨時表保存中間結果，也就是說 MySQL 在對查詢結果排序時使用了臨時表，常見於order by 或 group by。
• Using index：表示 SQL 操作中使用了覆蓋索引（Covering Index），避免了訪問表的數據行，效率高。
• Using index condition：表示 SQL 操作命中了索引，但不是所有的列數據都在索引樹上，還需要訪問實際的行記錄。
• Using where：表示 SQL 操作使用了 where 過濾條件（where條件不在索引中或者復合索引跨列查詢，所以需要回表查詢）
• Select tables optimized away：基於索引優化 MIN/MAX 操作或者 MyISAM 存儲引擎優化 COUNT(*) 操作，不必等到執行階段再進行計算，查詢執行計划生成的階段即可完成優化。
• Using join buffer (Block Nested Loop)：表示 SQL 操作使用了關聯查詢或者子查詢，且需要進行嵌套循環計算。

下面通過舉例說明。

數據准備：

CREATE TABLE `user` (
  `id` int(11) NOT NULL,
  `name` varchar(20) DEFAULT NULL,
  `sex` varchar(5) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

insert into user values(1, 'shenjian','no');
insert into user values(2, 'zhangsan','no');
insert into user values(3, 'lisi', 'yes');
insert into user values(4, 'lisi', 'no');

數據說明：

用戶表：id 主鍵索引，name 普通索引（非唯一），sex 無索引。

四行記錄：其中 name 普通索引存在重復記錄 lisi。

Using filesort

explain select * from user order by sex;

 

Extra 為 Using filesort 說明，得到所需結果集，需要對所有記錄進行文件排序。

這類 SQL 語句性能極差，需要進行優化。

典型的，在一個沒有建立索引的列上進行了 order by，就會觸發 filesort，常見的優化方案是，在 order by 的列上添加索引，避免每次查詢都全量排序。

 

 

 

 

Using temporary

explain select * from user group by name order by sex;

Extra 為 Using temporary 說明，需要建立臨時表（temporary table）來暫存中間結果。

這類 SQL 語句性能較低，往往也需要進行優化。

典型的 group by 和 order by 同時存在，且作用於不同的字段時，就會建立臨時表，以便計算出最終的結果集。

臨時表存在兩種引擎，一種是 Memory 引擎，一種是 MyISAM 引擎，如果返回的數據在 16M 以內（默認），且沒有大字段的情況下，使用 Memory 引擎，否則使用 MyISAM 引擎。 

Using index

EXPLAIN SELECT id FROM USER;

Extra 為 Using index 說明，SQL 所需要返回的所有列數據均在一棵索引樹上，而無需訪問實際的行記錄。

這類 SQL 語句往往性能較好。

Using index condition

explain select id, name, sex from user where name='shenjian';

Extra 為 Using index condition 說明，確實命中了索引，但不是所有的列數據都在索引樹上，還需要訪問實際的行記錄。

這類 SQL 語句性能也較高，但不如 Using index。

Using where

explain select * from user where sex='no';

Extra 為 Using where 說明，查詢的結果集使用了 where 過濾條件，比如上面的 SQL 使用了 sex = 'no' 的過濾條件

Select tables optimized away

EXPLAIN SELECT MAX(id) FROM USER;

 

比如上面的語句查詢 id 的最大值，因為 id 是主鍵索引，根據 B+Tree 的結構，天然就是有序存放的，所以不需要等到執行階段再進行計算，查詢執行計划生成的階段即可完成優化。

Using join buffer (Block Nested Loop)

explain select * from user where id in (select id from user where sex='no');

Extra 為 Using join buffer (Block Nested Loop) 說明，需要進行嵌套循環計算。內層和外層的 type 均為 ALL，rows 均為4，需要循環進行4*4次計算。

這類 SQL 語句性能往往也較低，需要進行優化。

典型的兩個關聯表 join，關聯字段均未建立索引，就會出現這種情況。常見的優化方案是，在關聯字段上添加索引，避免每次嵌套循環計算。