數據庫最常見的操作就是查詢了，我們經常要用"SELECT"語法對已有的表進行某種檢索，但是在實際應用中，查詢前我們并不知道該查詢會如何運行、會使用多少時間、會涉及多少字段和記錄，每次輸入了SQL語句，點擊運行，然后慢慢等待結果的出現，好的查詢語句效率很高，而有時候也會遇到查詢緩慢，久久沒有運行完成的情況。

由于我們并不知道實際查詢的時候數據庫里發生了什么，數據庫軟件是怎樣掃描表、怎樣使用索引，因此我們能感知的就只有查詢運行的時間，而往往在數據規模不大時，查詢是瞬間的，因此在寫SQL語句時也就比較隨意，也很少使用索引來加速查詢的速度。不過一旦數據規模增大，比如百萬、千萬、幾億的時候，我們寫同樣的查詢語句卻發現窗口遲遲沒有結果，這個時候才知道數據規模已經限制了我們自由查詢的速度。查詢優化和索引也就顯得很重要了。

那么，能不能在查詢前就能預先估計查詢究竟要涉及多少行、使用哪些索引、運行多久呢？答案是可以的，MySQL和SQL Server都提供了相應的功能和語法來實現，下面用一個擁有兩千多萬條記錄的表來說明如何進行查詢分析。該表有一個訪問時間字段。

MySql提供了EXPLAIN語法用來進行查詢分析，在SQL語句前加一個"EXPLAIN"即可。比如我們要分析如下SQL語句，該語句獲取特定時間段的訪問記錄總數。

EXPLAIN

SELECT COUNT(*) FROM ××××××

WHERE

TIME_INT>=UNIX_TIMESTAMP('2010-03-01 18:00:00') AND

TIME_INT

table | type | possible_keys | key | key_len | ref | rows | Extra

EXPLAIN列的解釋

table

顯示這一行的數據是關于哪張表的

type

這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為const、eq_reg、ref、range、indexhe和ALL(后面有詳細說明)

possible_keys

顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。可以為相關的域從WHERE語句中選擇一個合適的語句

key

實際使用的索引。如果為NULL，則沒有使用索引。很少的情況下，MYSQL會選擇優化不足的索引。這種情況下，可以在SELECT語句中使用USE

INDEX(indexname)來強制使用一個索引或者用IGNORE INDEX(indexname)來強制MYSQL忽略索引

key_len

使用的索引的長度。在不損失精確性的情況下，長度越短越好

ref

顯示索引的哪一列被使用了，如果可能的話，是一個常數

rows

MYSQL認為必須檢查的用來返回請求數據的行數

Extra

關于MYSQL如何解析查詢的額外信息。將在表4.3中討論，但這里可以看到的壞的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，結果是檢索會很慢

extra列返回的描述的意義

Distinct

一旦MYSQL找到了與行相聯合匹配的行，就不再搜索了

Not exists

MYSQL優化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標準的行，就不再搜索了

Range checked for each

Record(index map:#)

沒有找到理想的索引，因此對于從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，并用它來從表中返回行。這是使用索引的最慢的連接之一

Using filesort

看到這個的時候，查詢就需要優化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行

Using index

列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對表的全部的請求列都是同一個索引的部分的時候

Using temporary

看到這個的時候，查詢需要優化了。這里，MYSQL需要創建一個臨時表來存儲結果，這通常發生在對不同的列集進行ORDER BY上，而不是GROUP BY上

Where used

使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，并且連接類型ALL或index，這就會發生，或者是查詢有問題

不同連接類型的解釋(按照效率高低的順序排序)

system

表只有一行：system表。這是const連接類型的特殊情況

const

表中的一個記錄的最大值能夠匹配這個查詢(索引可以是主鍵或惟一索引)。因為只有一行，這個值實際就是常數，因為MYSQL先讀這個值然后把它當做常數來對待

eq_ref

在連接中，MYSQL在查詢時，從前面的表中，對每一個記錄的聯合都從表中讀取一個記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時使用

ref

這個連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分(比如，利用最左邊前綴)時發生。對于之前的表的每一個行聯合，全部記錄都將從表中讀出。這個類型嚴重依賴于根據索引匹配的記錄多少—越少越好

range

這個連接類型使用索引返回一個范圍中的行，比如使用>或

index

這個連接類型對前面的表中的每一個記錄聯合進行完全掃描(比ALL更好，因為索引一般小于表數據)

ALL

這個連接類型對于前面的每一個記錄聯合進行完全掃描，這一般比較糟糕，應該盡量避免

------------------------------

弄明白了explain語法返回的每一項結果，我們就能知道查詢大致的運行時間了，如果查詢里沒有用到索引、或者需要掃描的行過多(比如>=幾十萬行)，那么可以感到明顯的延遲。因此需要改變查詢方式或者新建索引。

比如沒有建索引，或者查詢寫得不好(沒有用到索引列)，會造成如下掃描所有兩千多萬條記錄的查詢方案(type為"ALL"，rows有兩千多萬)，這顯然是不可取的，運行的話至少需要一分鐘的時間。

總結

以上是生活随笔為你收集整理的执行计划 分析一条sql语句的效率 mysql_mysql的SQL语句执行计划分析:EXPLAIN的全部內容，希望文章能夠幫你解決所遇到的問題。

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