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

以下是自己總結(jié)；

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

type

type類型的性能比較

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

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

?

Extra

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/zhangjian816/p/10860230.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。