詳細請點擊?https://blog.csdn.net/qq_38293564/article/details/80883704

以下是自己總結；

接下來我們來重點看一下比較重要的幾個字段

type

type類型的性能比較

通常來說，不同的 type 類型的性能關系如下：?
ALL < index < range ~ index_merge < ref < eq_ref < const < system?
ALL 類型因為是全表掃描，因此在相同的查詢條件下，它是速度最慢的。?
而 index 類型的查詢雖然不是全表掃描，但是它掃描了所有的索引，因此比 ALL 類型的稍快。?
后面的幾種類型都是利用了索引來查詢數據，因此可以過濾部分或大部分數據，因此查詢效率就比較高了。

• • system: 表中只有一條數據，這個類型是特殊的 const 類型。
  • const: 針對主鍵或唯一索引的等值查詢掃描，最多只返回一行數據。const 查詢速度非常快，因為它僅僅讀取一次即可。?
    例如下面的這個查詢，它使用了主鍵索引，因此 type 就是 const 類型的：explain select * from user_info where id = 2\G;
  • eq_ref: 此類型通常出現在多表的 join 查詢，表示對于前表的每一個結果，都只能匹配到后表的一行結果，并且查詢的比較操作通常是 =，查詢效率較高。例如：EXPLAIN SELECT * FROM user_info，order_info WHERE user_info.id = order_info.user_id\G;
  • ref: 此類型通常出現在多表的 join 查詢，針對于非唯一或非主鍵索引，或者是使用了 最左前綴 規則索引的查詢。?
    例如下面這個例子中，就使用到了 ref 類型的查詢：EXPLAIN SELECT * FROM user_info，order_info WHERE user_info.id = order_info.user_id AND order_info.user_id = 5\G;
  • range: 表示使用索引范圍查詢，通過索引字段范圍獲取表中部分數據記錄。這個類型通常出現在 =， <>，>，>=，<，<=，IS NULL，<=>，BETWEEN，IN() 操作中。?
    當 type 是 range 時，那么 EXPLAIN 輸出的 ref 字段為 NULL，并且 key_len 字段是此次查詢中使用到的索引的最長的那個。例如下面的例子就是一個范圍查詢：EXPLAIN SELECT * FROM user_info WHERE id BETWEEN 2 AND 8\G;
  • index: 表示全索引掃描(full index scan)，和 ALL 類型類似，只不過 ALL 類型是全表掃描，而 index 類型則僅僅掃描所有的索引，而不掃描數據。?
    index 類型通常出現在：所要查詢的數據直接在索引樹中就可以獲取到，而不需要掃描數據，當是這種情況時，Extra 字段 會顯示 Using index。例如：EXPLAIN SELECT name FROM user_info \G;上面的例子中，我們查詢的 name 字段恰好是一個索引，因此我們直接從索引中獲取數據就可以滿足查詢的需求了，而不需要查詢表中的數據. 因此這樣的情況下，type 的值是 index，并且 Extra 的值是 Using index。
  • ALL: 表示全表掃描，這個類型的查詢是性能最差的查詢之一。通常來說，我們的查詢不應該出現 ALL 類型的查詢，因為這樣的查詢在數據量大的情況下，對數據庫的性能是巨大的災難. 如一個查詢是 ALL 類型查詢，那么一般來說可以對相應的字段添加索引來避免。?
    下面是一個全表掃描的例子，可以看到，在全表掃描時，possible_keys 和 key 字段都是 NULL，表示沒有使用到索引，并且 rows 十分巨大，因此整個查詢效率是十分低下的。EXPLAIN SELECT age FROM user_info WHERE age = 20 \G;

?

Extra

• • Using filesort?
    當 Extra 中有 Using filesort 時，表示 MySQL 需額外的排序操作，不能通過索引順序達到排序效果。一般有 Using filesort 都建議優化去掉，因為這樣的查詢 CPU 資源消耗大。?
    例如下面的例子：EXPLAIN SELECT * FROM order_info ORDER BY product_name \G;
    我們的索引是KEY `user_product_detail_index` (`user_id`, `product_name`, `productor`)
    但是上面的查詢中根據 product_name 來排序，因此不能使用索引進行優化，進而會產生 Using filesort。?
    如果我們將排序依據改為 ORDER BY user_id, product_name，那么就不會出現 Using filesort 了。例如：EXPLAIN SELECT * FROM order_info ORDER BY user_id, product_name \G;
    
  • Using index?
    “覆蓋索引掃描”，表示查詢在索引樹中就可查找所需數據，不用掃描表數據文件，往往說明性能不錯。
  • Using temporary?
    查詢有使用臨時表，一般出現于排序，分組和多表 join 的情況，查詢效率不高，建議優化。

?

轉載于:https://www.cnblogs.com/zhangjian816/p/10860230.html

總結

以上是生活随笔為你收集整理的转：MySQL性能优化神器Explain使用分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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