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