MySQL查詢優化之explain的深入解析【轉載】

原創 jimmee 2018-12-07 21:06

可參考mysql的官方文檔：http://dev.mysql.com/doc/refman/5.7/en/explain-output.html

在分析查詢性能時，考慮EXPLAIN關鍵字同樣很管用。EXPLAIN關鍵字一般放在SELECT查詢語句的前面，用於描述MySQL如何執行查詢操作、以及MySQL成功返回結果集需要執行的行數。explain 可以幫助我們分析 select 語句,讓我們知道查詢效率低下的原因,從而改進我們查詢,讓查詢優化器能夠更好的工作。

一、MySQL 查詢優化器是如何工作的
MySQL 查詢優化器有幾個目標,但是其中最主要的目標是儘可能地使用索引,並且使用最嚴格的索引來消除儘可能多的數據行。最終目標是提交 SELECT 語句查找數據行,而不是排除數據行。優化器試圖排除數據行的原因在於它排除數據行的速度越快,那麼找到與條件匹配的數據行也就越快。如果能夠首先進行最嚴格的測試,查詢就可以執行地更快。
EXPLAIN 的每個輸出行提供一個表的相關信息,並且每個行包括下面的列: 

項 說明
id  MySQL Query Optimizer 選定的執行計劃中查詢的序列號。表示查詢中執行 select 子句或操作表的順序,id 值越大優先級越高,越先被執行。id 相同,執行順序由上至下。

 

select_type 查詢類型 說明
SIMPLE 簡單的 select 查詢,不使用 union 及子查詢
PRIMARY 最外層的 select 查詢
UNION UNION 中的第二個或隨後的 select 查詢,不 依賴於外部查詢的結果集
DEPENDENT UNION UNION 中的第二個或隨後的 select 查詢,依 賴於外部查詢的結果集
SUBQUERY 子查詢中的第一個 select 查詢,不依賴於外 部查詢的結果集
DEPENDENT SUBQUERY 子查詢中的第一個 select 查詢,依賴於外部 查詢的結果集
DERIVED 用於 from 子句裏有子查詢的情況。 MySQL 會 遞歸執行這些子查詢, 把結果放在臨時表裏。
UNCACHEABLE SUBQUERY 結果集不能被緩存的子查詢,必須重新爲外 層查詢的每一行進行評估。
UNCACHEABLE UNION UNION 中的第二個或隨後的 select 查詢,屬 於不可緩存的子查詢

 

項 說明
table  輸出行所引用的表

 

type 重要的項,顯示連接使用的類型,按最 優到最差的類型排序 說明
system  表僅有一行(=系統表)。這是 const 連接類型的一個特例。
const  const 用於用常數值比較 PRIMARY KEY 時。當 查詢的表僅有一行時,使用 System。
eq_ref 

One row is read from this table for each combination of rows from the previous tables. Other than the system and const types, this is the best possible join type. It is used when all parts of an index are used by the join and the index is a PRIMARY KEY or UNIQUE NOT NULL index.

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;
ref 

All rows with matching index values are read from this table for each combination of rows from the previous tables. ref is used if the join uses only a leftmost prefix of the key or if the key is not a PRIMARY KEY or UNIQUE index (in other words, if the join cannot select a single row based on the key value). If the key that is used matches only a few rows, this is a good join type.

ref can be used for indexed columns that are compared using the = or <=> operator. In the following examples, MySQL can use a ref join to process ref_table:

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;
ref_or_null 

This join type is like ref, but with the addition that MySQL does an extra search for rows that contain NULL values. This join type optimization is used most often in resolving subqueries. In the following examples, MySQL can use a ref_or_null join to process ref_table:

SELECT * FROM ref_table
  WHERE key_column=expr OR key_column IS NULL;
index_merge  說明索引合併優化被使用了。
unique_subquery 

This type replaces ref for some IN subqueries of the following form:

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery is just an index lookup function that replaces the subquery completely for better efficiency.
index_subquery 

This join type is similar to unique_subquery. It replaces IN subqueries, but it works for nonunique indexes in subqueries of the following form:

value IN (SELECT key_column FROM single_table WHERE some_expr)
range 

Only rows that are in a given range are retrieved, using an index to select the rows. The key column in the output row indicates which index is used. The key_len contains the longest key part that was used. The ref column is NULL for this type.

range can be used when a key column is compared to a constant using any of the =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, or IN() operators:

SELECT * FROM tbl_name
  WHERE key_column = 10;

SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name
  WHERE key_part1 = 10 AND key_part2 IN (10,20,30);
index 

The index join type is the same as ALL, except that the index tree is scanned. This occurs two ways:

  • If the index is a covering index for the queries and can be used to satisfy all data required from the table, only the index tree is scanned. In this case, the Extra column says Using index. An index-only scan usually is faster than ALL because the size of the index usually is smaller than the table data.

  • A full table scan is performed using reads from the index to look up data rows in index order. Uses index does not appear in the Extra column.

MySQL can use this join type when the query uses only columns that are part of a single index.
all  最壞的情況,從頭到尾全表掃描。



項 說明
possible_keys  指出 MySQL 能在該表中使用哪些索引有助於 查詢。如果爲空,說明沒有可用的索引。

 

項 說明
key  MySQL 實際從 possible_key 選擇使用的索引。 如果爲 NULL,則沒有使用索引。很少的情況 下,MYSQL 會選擇優化不足的索引。這種情 況下,可以在 SELECT 語句中使用 USE INDEX (indexname)來強制使用一個索引或者用 IGNORE INDEX(indexname)來強制 MYSQL 忽略索引

 

項 說明
key_len  使用的索引的長度。在不損失精確性的情況 下,長度越短越好。

 

項 說明
ref  顯示索引的哪一列被使用了

 

項 說明
rows  MYSQL 認爲必須檢查的用來返回請求數據的行數

 

項 說明
rows  MYSQL 認爲必須檢查的用來返回請求數據的行數

 

extra 中出現以下 2 項意味着 MYSQL 根本不能使用索引,效率會受到重大影響。應儘可能對此進行優化。 

extra 項 說明
Using filesort  表示 MySQL 會對結果使用一個外部索引排序,而不是從表裏按索引次序讀到相關內容。可能在內存或者磁盤上進行排序。MySQL 中無法利用索引完成的排序操作稱爲“文件排序”
Using temporary  表示 MySQL 在對查詢結果排序時使用臨時表。常見於排序 order by 和分組查詢 group by。

下面來舉一個例子來說明下 explain 的用法。 
先來一張表:

複製代碼代碼如下:

CREATE TABLE IF NOT EXISTS `article` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`author_id` int(10) unsigned NOT NULL,
`category_id` int(10) unsigned NOT NULL,
`views` int(10) unsigned NOT NULL,
`comments` int(10) unsigned NOT NULL,
`title` varbinary(255) NOT NULL,
`content` text NOT NULL,
PRIMARY KEY (`id`)
);


再插幾條數據:

複製代碼代碼如下:

INSERT INTO `article`
(`author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES
(1, 1, 1, 1, '1', '1'),
(2, 2, 2, 2, '2', '2'),
(1, 1, 3, 3, '3', '3');


需求:
查詢 category_id 爲 1 且 comments 大於 1 的情況下,views 最多的 article_id。 
先查查試試看:

複製代碼代碼如下:

EXPLAIN
SELECT author_id
FROM `article`
WHERE category_id = 1 AND comments > 1
ORDER BY views DESC
LIMIT 1\G


看看部分輸出結果: 

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: article
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 3
        Extra: Using where; Using filesort
1 row in set (0.00 sec)


很顯然,type 是 ALL,即最壞的情況。Extra 裏還出現了 Using filesort,也是最壞的情況。優化是必須的。

 

嗯,那麼最簡單的解決方案就是加索引了。好,我們來試一試。查詢的條件裏即 where 之後共使用了 category_id,comments,views 三個字段。那麼來一個聯合索引是最簡單的了。

複製代碼代碼如下:

ALTER TABLE `article` ADD INDEX x ( `category_id` , `comments`, `views` );


結果有了一定好轉,但仍然很糟糕:

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: article
         type: range
possible_keys: x
          key: x
      key_len: 8
          ref: NULL
         rows: 1
        Extra: Using where; Using filesort
1 row in set (0.00 sec)


type 變成了 range,這是可以忍受的。但是 extra 裏使用 Using filesort 仍是無法接受的。但是我們已經建立了索引,爲啥沒用呢?這是因爲按照 BTree 索引的工作原理,先排序 category_id,如果遇到相同的 category_id 則再排序 comments,如果遇到相同的 comments 則再排序 views。當 comments 字段在聯合索引裏處於中間位置時,因comments > 1 條件是一個範圍值(所謂 range),MySQL 無法利用索引再對後面的 views 部分進行檢索,即 range 類型查詢字段後面的索引無效。
那麼我們需要拋棄 comments,刪除舊索引:

複製代碼代碼如下:

 DROP INDEX x ON article;


然後建立新索引:

複製代碼代碼如下:

ALTER TABLE `article` ADD INDEX y ( `category_id` , `views` ) ;


接着再運行查詢:

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: article
         type: ref
possible_keys: y
          key: y
      key_len: 4
          ref: const
         rows: 1
        Extra: Using where
1 row in set (0.00 sec)


可以看到,type 變爲了 ref,Extra 中的 Using filesort 也消失了,結果非常理想。
再來看一個多表查詢的例子。
首先定義 3個表 class 和 room。

複製代碼代碼如下:

CREATE TABLE IF NOT EXISTS `class` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`card` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE IF NOT EXISTS `book` (
`bookid` int(10) unsigned NOT NULL AUTO_INCREMENT,
`card` int(10) unsigned NOT NULL,
PRIMARY KEY (`bookid`)
);
CREATE TABLE IF NOT EXISTS `phone` (
`phoneid` int(10) unsigned NOT NULL AUTO_INCREMENT,
`card` int(10) unsigned NOT NULL,
PRIMARY KEY (`phoneid`)
) engine = innodb;


然後再分別插入大量數據。插入數據的php腳本： 

複製代碼代碼如下:

<?php
$link = mysql_connect("localhost","root","870516");
mysql_select_db("test",$link);
for($i=0;$i<10000;$i++)
{
    $j   = rand(1,20);
    $sql = " insert into class(card) values({$j})";
    mysql_query($sql);
}
for($i=0;$i<10000;$i++)
{
    $j   = rand(1,20);
    $sql = " insert into book(card) values({$j})";
    mysql_query($sql);
}
for($i=0;$i<10000;$i++)
{
    $j   = rand(1,20);
    $sql = " insert into phone(card) values({$j})";
    mysql_query($sql);
}
mysql_query("COMMIT");
?>


然後來看一個左連接查詢: 

複製代碼代碼如下:

explain select * from class left join book on class.card = book.card\G


分析結果是:

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
2 rows in set (0.00 sec)


顯然第二個 ALL 是需要我們進行優化的。
建立個索引試試看:

複製代碼代碼如下:

ALTER TABLE `book` ADD INDEX y ( `card`);

 

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ref
possible_keys: y
          key: y
      key_len: 4
          ref: test.class.card
         rows: 1000
        Extra: 
2 rows in set (0.00 sec)


可以看到第二行的 type 變爲了 ref,rows 也變成了 1741*18,優化比較明顯。這是由左連接特性決定的。LEFT JOIN 條件用於確定如何從右表搜索行,左邊一定都有,所以右邊是我們的關鍵點,一定需要建立索引。
刪除舊索引:

複製代碼代碼如下:

DROP INDEX y ON book;


建立新索引。

複製代碼代碼如下:

ALTER TABLE `class` ADD INDEX x ( `card`);


結果

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
2 rows in set (0.00 sec)


基本無變化。
       然後來看一個右連接查詢:

複製代碼代碼如下:

explain select * from class right join book on class.card = book.card;


分析結果是:

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ref
possible_keys: x
          key: x
      key_len: 4
          ref: test.book.card
         rows: 1000
        Extra: 
2 rows in set (0.00 sec)


優化較明顯。這是因爲 RIGHT JOIN 條件用於確定如何從左表搜索行,右邊一定都有,所以左邊是我們的關鍵點,一定需要建立索引。
刪除舊索引:

複製代碼代碼如下:

DROP INDEX x ON class;


建立新索引。

複製代碼代碼如下:

ALTER TABLE `book` ADD INDEX y ( `card`);


結果

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
2 rows in set (0.00 sec)


基本無變化。 

 

最後來看看 inner join 的情況:

複製代碼代碼如下:

explain select * from class inner join book on class.card = book.card;


結果: 

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ref
possible_keys: x
          key: x
      key_len: 4
          ref: test.book.card
         rows: 1000
        Extra: 
2 rows in set (0.00 sec)


刪除舊索引: 

複製代碼代碼如下:

DROP INDEX y ON book;


結果

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
2 rows in set (0.00 sec)


建立新索引。

複製代碼代碼如下:

ALTER TABLE `class` ADD INDEX x ( `card`);


結果

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
2 rows in set (0.00 sec)


綜上所述,inner join 和 left join 差不多,都需要優化右表。而 right join 需要優化左表。

 

我們再來看看三表查詢的例子

添加一個新索引：

複製代碼代碼如下:

ALTER TABLE `phone` ADD INDEX z ( `card`);
ALTER TABLE `book` ADD INDEX y ( `card`);

 

複製代碼代碼如下:

explain select * from class left join book on class.card=book.card left join phone on book.card = phone.card;

 

複製代碼代碼如下:

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: class
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 20000
        Extra: 
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: book
         type: ref
possible_keys: y
          key: y
      key_len: 4
          ref: test.class.card
         rows: 1000
        Extra: 
*************************** 3. row ***************************
           id: 1
  select_type: SIMPLE
        table: phone
         type: ref
possible_keys: z
          key: z
      key_len: 4
          ref: test.book.card
         rows: 260
        Extra: Using index
3 rows in set (0.00 sec)


後 2 行的 type 都是 ref 且總 rows 優化很好,效果不錯。

MySql 中的 explain 語法可以幫助我們改寫查詢,優化表的結構和索引的設置,從而最大地提高查詢效率。當然,在大規模數據量時,索引的建立和維護的代價也是很高的,往往需要較長的時間和較大的空間,如果在不同的列組合上建立索引,空間的開銷會更大。因此索引最好設置在需要經常查詢的字段中。

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

linux CentOS7 mysql 源碼安裝和rpm安裝

今天是安裝linux mysql第三天，終於安裝成功了。 第一種方法，源碼安裝。 下載 cmake-2.8.10.2.tar.gz 和 mysql-5.6.4-m7.tar.gz 上傳到服務器解壓完成 1.在cmake-2.8.10.2這

weixin_38081382 2020-07-08 12:31:47

linux mysql ERROR 1820 (HY000): Unknown error 1820

安裝好mysql登錄進去mysql中，使用查詢，創建命令都不行，還報錯。 網上查找後，發現雖然使用我上一遍文章修改了密碼，但是mysql中並沒有設置密碼，需要在mysql中再設置一下密碼  執行 SET PASSWORD = PASSWO

weixin_38081382 2020-07-08 12:31:47

Java之mySQL數據庫事務隔離級別

問題 同一個應用程序中的多個事務或不同應用程序中的多個事務在同一個數據集上併發執行時, 可能會出現許多意外的問題，這些問題可分爲如下三種類型： 髒讀(Drity Read)： 已知有兩個事務A和B, A讀取了已經被B更新但還沒

这个名字真难起 2020-07-08 12:03:47

Java之mySQL數據庫表

字段類型 整數類型 tinyInt：很小的整數， smallint：小的整數 mediumint：中等大小的整數 int：普通大小的整數 小數類型 float(m,d)：單精度浮點數，m表示數字長度，d表示小數位數，例如floa

这个名字真难起 2020-07-08 12:03:46

mysql預處理語句提取變量，實現動態執行SQL語句

爲了項目在長期使用過程中，數據庫仍能夠保持較好的性能，考慮將數據庫表分爲當前表和歷史表。當前錶針對不同客戶，分別存儲在不同的表中。因爲需要在mysql的存儲過程中實現動態的指向不同的表進行操作。 首先,mysql的預處理語句如果帶參數，每

pengdayong77 2020-07-08 12:37:23

面試準備季——MyBatis 面試專題（含答案）

寫在前面：2020年面試必備的Java後端進階面試題總結了一份複習指南在Github上，內容詳細，圖文並茂，有需要學習的朋友可以Star一下！ GitHub地址：https://github.com/abel-max/Java-S

毛发旺盛的程序员 2020-07-08 12:27:20

Flex+java開發環境配置

     最近在做個項目。前端是用flex來寫，後臺用java，數據庫就用mysql。定了以後開始配環境。網上這方面的資料很多都是不負責任的，照着來的話也會有不少的問題，把自己的配置方法寫下來，希望需要的人能用得上。  需要下載的軟件 M

duran1986 2020-07-08 12:24:31

MySQL：CentOS 7通過yum安裝MariaDB

如何在CentOS 7下通過yum安裝MariaDB呢？ 這裏附上大佬的安裝步驟： https://zhuanlan.zhihu.com/p/49046496 博主就是按照這個步驟來的，炒雞詳細~相信你也能看明白 |ू･ω･` )

ETalien_ 2020-07-08 12:19:01

MySQL：外鍵及外鍵的使用

外鍵及外鍵的使用 如果公共關鍵字在一個關係中是主關鍵字，那麼這個公共關鍵字被稱爲另一個關係的外鍵。 由此可見，外鍵表示了兩個關係之間的相關聯繫。以另一個關係的外鍵作主關鍵字的表被稱爲主表，具有此外鍵的表被稱爲主表的從表。外鍵又稱作

ETalien_ 2020-07-08 12:19:01

MySQL：建庫建表等簡單操作

庫的相關操作 – 查看已有庫 SHOW DATABASES; SHOW DATABASES; SHOW DATABASES\G – 新建庫的操作 CREATE DATABASE 庫名; CREATE DATABASE `ET`;

ETalien_ 2020-07-08 12:19:01

linux 下安裝 mysql5.6.30

以下安裝步驟是本人以前操作的過程步驟，不保證100%正確，如果在使用過程出現異常請查閱其他相關資料。 1、下載mysql5.6，地址：http://dev.mysql.com/downloads/mysql/ 我們這下載：mysql

华华鱼 2020-07-08 12:16:40

【數據庫-MySQL】mysql日誌詳解及性能優化

mysql日誌分爲四大類：慢查詢日誌，查詢日誌，錯誤日誌，二進制日誌 一.慢查詢日誌：大於慢查詢時間的語句，都會記錄在慢查詢日誌中 1.查看慢查詢是否開啓 show variables like "slow_query_log"; 如下：

斯台普斯的少年 2020-07-08 12:15:14

Mysql疑難雜症收集

  Mysql疑難雜症收集 By Eagoo 　　　　一、可疑問題： 　　　　　　　　mysql>show processlist; 　　　　

单线程的娃 2020-07-08 12:00:56

python 操作 MySql 數據庫

準備工作 : 安裝 pymysql 命令：pip install pymysql 重要函數 函數 說明 connect 創建鏈接 cursor  創建一個遊標 commit 事務提交，如果沒有設爲自動提交，則每次操作後必須提交事務，否則操

浮煌 2020-07-08 11:43:28

談談mysql locate函數

大家都知道，當我們mysql需要使用模糊查詢的時候，往往會使用like去做相關查詢條件的模糊匹配，但是很多場景下，使用locate會獲取同樣的效果 create table user( id int primary key au

baomw 2020-07-08 11:43:17