EXPLAIN tbl_name
or EXPLAIN SELECT select_options
EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一個同義詞。
當你在一條SELECT語句前放上關鍵詞EXPLAIN，MySQL解釋它將如何處理SELECT，提供有關表如何聯結和以什么次序聯結的信息。
借助于EXPLAIN，你可以知道你什么時候必須為表加入索引以得到一個使用索引找到記錄的更快的SELECT。你也能知道優化器是否以一個最佳次序聯結表。為了強制優化器對一個SELECT語句使用一個特定聯結次序，增加一個STRAIGHT_JOIN子句。
對于非簡單的聯結，EXPLAIN為用于SELECT語句中的每個表返回一行信息。表以他們將被讀入的順序被列出。MySQL用一邊掃描多次聯結的方式解決所有聯結，這意味著MySQL從第一個表中讀一行，然后找到在第二個表中的一個匹配行，然后在第3個表中等等。當所有的表被處理完，它輸出選擇的列并且回溯表列表直到找到一個表有更多的匹配行，從該表讀入下一行并繼續處理下一個表。
從EXPLAIN的輸出包括下面列：
table
輸出的行所引用的表。
type
聯結類型。各種類型的信息在下面給出。
possible_keys
possible_keys列指出MySQL能使用哪個索引在該表中找到行。注意，該列完全獨立于表的次序。這意味著在possible_keys中的某些鍵實際上不能以生成的表次序使用。如果該列是空的，沒有相關的索引。在這種情況下，你也許能通過檢驗WHERE子句看是否它引用某些列或列不是適合索引來提高你的查詢性能。如果是這樣，創造一個適當的索引并且在用EXPLAIN檢查查詢。見7.8 ALTER TABLE句法。為了看清一張表有什么索引，使用SHOW INDEX FROM tbl_name。
key
key列顯示MySQL實際決定使用的鍵。如果沒有索引被選擇，鍵是NULL。
key_len
key_len列顯示MySQL決定使用的鍵長度。如果鍵是NULL，長度是NULL。注意這告訴我們MySQL將實際使用一個多部鍵值的幾個部分。
ref
ref列顯示哪個列或常數與key一起用于從表中選擇行。
rows
rows列顯示MySQL相信它必須檢驗以執行查詢的行數。
Extra
如果Extra列包括文字Only index，這意味著信息只用索引樹中的信息檢索出的。通常，這比掃描整個表要快。如果Extra列包括文字where used，它意味著一個WHERE子句將被用來限制哪些行與下一個表匹配或發向客戶。
不同的聯結類型列在下面，以最好到最差類型的次序：
system
表僅有一行(=系統表)。這是const聯結類型的一個特例。
const
表有最多一個匹配行，它將在查詢開始時被讀取。因為僅有一行，在這行的列值可被剩下的優化器認為是常數。 const表很快，因為它們只讀取一次！
eq_ref
對于每個來自于先前的表的行組合，從該表中讀取一行。這可能是最好的聯結類型，除了const類型。它用在一個索引的所有部分被聯結使用并且索引是UNIQUE或PRIMARY KEY。
ref
對于每個來自于先前的表的行組合，所有有匹配索引值的行將從這張表中讀取。如果聯結只使用鍵的最左面前綴，或如果鍵不是UNIQUE或PRIMARY KEY（換句話說，如果聯結不能基于鍵值選擇單個行的話)，使用ref。如果被使用的鍵僅僅匹配一些行，該聯結類型是不錯的。
range
只有在一個給定范圍的行將被檢索，使用一個索引選擇行。ref列顯示哪個索引被使用。
index
這與ALL相同，除了只有索引樹被掃描。這通常比ALL快，因為索引文件通常比數據文件小。
ALL
對于每個來自于先前的表的行組合，將要做一個完整的表掃描。如果表格是第一個沒標記const的表，這通常不好，并且通常在所有的其他情況下很差。你通?？梢酝ㄟ^增加更多的索引來避免ALL，使得行能從早先的表中基于常數值或列值被檢索出。
通過相乘EXPLAIN輸出的rows行的所有值，你能得到一個關于一個聯結要多好的提示。這應該粗略地告訴你MySQL必須檢驗多少行以執行查詢。當你使用max_join_size變量限制查詢時，也用這個數字。見10.2.3 調節服務器參數。
下列例子顯示出一個JOIN如何能使用EXPLAIN提供的信息逐步被優化。
假定你有顯示在下面的SELECT語句，你使用EXPLAIN檢驗：
EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,
tt.ProjectReference, tt.EstimatedShipDate,
tt.ActualShipDate, tt.ClientID,
tt.ServiceCodes, tt.RepetitiveID,
tt.CurrentProcess, tt.CurrentDPPerson,
tt.RecordVolume, tt.DPPrinted, et.COUNTRY,
et_1.COUNTRY, do.CUSTNAME
FROM tt, et, et AS et_1, do
WHERE tt.SubmitTime IS NULL
AND tt.ActualPC = et.EMPLOYID
AND tt.AssignedPC = et_1.EMPLOYID
AND tt.ClientID = do.CUSTNMBR;
對于這個例子，假定：
被比較的列被聲明如下： 表 列 列類型
tt ActualPC CHAR(10)
tt AssignedPC CHAR(10)
tt ClientID CHAR(10)
et EMPLOYID CHAR(15)
do CUSTNMBR CHAR(15)
表有顯示在下面的索引： 表 索引
tt ActualPC
tt AssignedPC
tt ClientID
et EMPLOYID（主鍵）
do CUSTNMBR（主鍵）
tt.ActualPC值不是均勻分布的。
開始，在任何優化被施行前，EXPLAIN語句產生下列信息：
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
do ALL PRIMARY NULL NULL NULL 2135
et_1 ALL PRIMARY NULL NULL NULL 74
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872
range checked for each record (key map: 35)
因為type對每張表是ALL，這個輸出顯示MySQL正在對所有表進行一個完整聯結！這將花相當長的時間，因為必須檢驗每張表的行數的乘積次數！對于一個實例，這是74 * 2135 * 74 * 3872 = 45,268,558,720行。如果表更大，你只能想象它將花多長時間……
如果列聲明不同，這里的一個問題是MySQL(還)不能高效地在列上使用索引。在本文中，VARCHAR和CHAR是相同的，除非他們聲明為不同的長度。因為tt.ActualPC被聲明為CHAR(10)并且et.EMPLOYID被聲明為CHAR(15)，有一個長度失配。
為了修正在列長度上的不同，使用ALTER TABLE將ActualPC的長度從10個字符變為15個字符：
mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);
現在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)，再執行EXPLAIN語句產生這個結果：
table type possible_keys key key_len ref rows Extra
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
do ALL PRIMARY NULL NULL NULL 2135
range checked for each record (key map: 1)
et_1 ALL PRIMARY NULL NULL NULL 74
range checked for each record (key map: 1)
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
這不是完美的，但是是好一些了(rows值的乘積少了一個74一個因子)，這個版本在幾秒內執行。
第2種改變能消除tt.AssignedPC = et_1.EMPLOYID和tt.ClientID = do.CUSTNMBR比較的列的長度失配：
mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),
MODIFY ClientID VARCHAR(15);
現在EXPLAIN產生的輸出顯示在下面：
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
tt ref AssignedPC,ClientID,ActualPC ActualPC 15 et.EMPLOYID 52 where used
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
這“幾乎”象它能得到的一樣好。
剩下的問題是，缺省地，MySQL假設在tt.ActualPC列的值是均勻分布的，并且對tt表不是這樣。幸好，很容易告訴MySQL關于這些：
shell> myisamchk --analyze PATH_TO_MYSQL_DATABASE/tt
shell> mysqladmin refresh
現在聯結是“完美”的了，而且EXPLAIN產生這個結果：
table type possible_keys key key_len ref rows Extra
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
注意在從EXPLAIN輸出的rows列是一個來自MySQL聯結優化器的“教育猜測”；為了優化查詢，你應該檢查數字是否接近事實。如果不是，你可以通過在你的SELECT語句里面使用STRAIGHT_JOIN并且試著在在FROM子句以不同的次序列出表，可能得到更好的性能。
轉載：http://www.99net.net/doc/database/1076488199/1076552137.html