Mysql之EXPLAIN命令檢視SQL執行計畫

[root@vm_0_5_centos ~]# mysqldumpslow -a /var/log/mariadb/slow_query_log.txt
reading mysql slow query log from /var/log/mariadb/slow_query_log.txt
count: 4  time=21.46s (85s)  lock=0.00s (0s)  rows_sent=25615.0 (102460), rows_examined=85985.0 (343940), root[root]@[218.17.185.19]
select * from `order` where username="1372874***x"
count: 2  time=18.81s (37s)  lock=0.00s (0s)  rows_sent=25465.0 (50930), rows_examined=25540.0 (51080), root[root]@[218.17.185.19]
select * from `order` where username="1372874***x" and side="buy"

通過mysqldumpslow分析慢查詢日誌，已經得到了具體的sql；

接下來就要分析sql執行慢的原因，也就是分析sql的執行計畫。

使用示例：

explain select * from `order` where username="1372874***x";

執行結果：

id sql執行的順序的標識,從大到小的執行，同數值從上到下執行

select_type 查詢型別，例如******、primary、union。。

table 可能是表名、表的別名，或者乙個為查詢產生的臨時表

type 連線型別

possible_keys 可能用到的索引，如果乙個列值多於3個，則說明引用的索引太多，或者存在乙個無效的索引

key key列顯示mysql實際決定使用的鍵（索引），正在用到的索引。如果沒有選擇索引，鍵是null

key_len 索引鍵的長度，用於確認索引的有效性，及多列索引中用到的索引的數量非常重要

rows 顯示mysql認為它執行查詢時必須檢查的行數，採用巢狀演算法，如第一列查出需要2行，第二列查出有10行，則數值為20，值越大，表示查詢用到的數量越多

extra 額外的資訊

rows 查詢過濾出的資料行數

key 實際使用的索引

type -- 連線型別

這裡只記錄和理解最重要且經常遇見的六種型別，它們分別是

all,index,range,ref,eq_ref，const。從左到右，它們的效率依次是增強的

all 這便是所謂的「全表掃瞄」用all去查詢資料就好比這樣的乙個情形：s學校有倆萬人，我告訴你你給我找到小明，然後你怎麼做呢！你當然是把全校倆萬人挨個找一遍，即使你很幸運第乙個人便找到了小明，但是你仍然不能停下，因為你無法確認是否有另外乙個小明存在，直到你把倆萬人找完為止。所以，基本所有情況，我們都要避免這樣型別的查詢，除非你不得不這樣做。

index

這種連線型別只是另外一種形式的全表掃瞄，只不過它的掃瞄順序是按照索引的順序

range 指的是有範圍的索引掃瞄，相對於index的全索引掃瞄，它有範圍限制

ref 出現該連線型別的條件是：查詢條件列使用了索引而且不為主鍵和unique。其實，意思就是雖然使用了索引，但該索引列的值並不唯一，有重複。這樣即使使用索引快速查詢到了第一條資料，仍然不能停止，要進行目標值附近的小範圍掃瞄。但它的好處是它並不需要掃全表，因為索引是有序的，即便有重複值，也是在乙個非常小的範圍內掃瞄。

ref_eq 與 ref相比牛的地方是，它知道這種型別的查詢結果集只有乙個？什麼情況下結果集只有乙個呢！那便是使用了主鍵或者唯一性索引進行查詢的情況

const 通常情況下，如果將乙個主鍵放置到where後面作為條件查詢，mysql優化器就能把這次查詢優化轉化為乙個常量。至於如何轉化以及何時轉化，這個取決於優化器

extra列返回的描述的意義

select tables optimized away 直接走的索引結果,一般出現在索引列的max\min\count\order by

using where 使用到查詢條件沒有走索引或者索引失效,或者部分條件沒有走索引

using index 全索引掃瞄查詢條件裡只有查詢列

using temporary 使用到了臨時表儲存過程資料

using filesort 使用到了檔案排序

system 唯一值返回

key_len長度的計算意義：

解決復合索引中到底哪個列被使用

如果復合索引中被使用的key_len一直很小，那麼就需要考慮是否需要這個復合索引

執行計畫並不能簡單的通過某個字段直觀的確定sql是否有問題，而是要通過多個字段組合分析。

接下來就是對執行計畫的分析——確定sql是否需要優化。

1、看rows是不是很大

2、有沒有使用合適的key

3、看extra擴充套件資訊

如果rows很大，又沒有使用key，則需要優化

如果rows很大，extra提示沒有走索引，則需要優化

大表走索引，小表不走索引。

Mysql之EXPLAIN命令檢視SQL執行計畫

MySQL的explain命令詳解

MySQL中EXPLAIN命令詳解

MySQL中EXPLAIN解釋命令

Mysql之EXPLAIN命令檢視SQL執行計畫

MySQL的explain命令詳解

MySQL中EXPLAIN命令詳解

MySQL中EXPLAIN解釋命令

相關推薦