1.使用explain語句去檢視分析結果 
如explain select * from test1 where id=1;會出現：id selecttype table type possible_keys key key_len ref rows extra各列。

其中， 
type=const表示通過索引一次就找到了； 
key=primary的話，表示使用了主鍵； 
type=all,表示為全表掃描； 
key=null表示沒用到索引。

type=ref，因為這時認為是多個匹配行，在聯合查詢中，一般為REF。

2.MYSQL中的組合索引 
假設表有id,key1,key2,key3,把三者形成一個組合索引，則如： 
複製程式碼 程式碼如下:

1.   where key1=....
2.   where key1=1 and key2=2
3.   where key1=3 and key2=3 and key3=2

根據最左字首原則，這些都是可以使用索引的，如from test where key1=1 order by key3，用explain分析的話，只用到了normal_key索引，但只對where子句起作用，而後面的order by需要排序。

3.使用慢查詢分析（實用）
在my.ini中： 
long_query_time=1 
log-slow-queries=d:\mysql5\logs\mysqlslow.log 
把超過1秒的記錄在慢查詢日誌中 
可以用mysqlsla來分析之。也可以在mysqlreport中，有如 
DMS分別分析了select ,update,insert,delete,replace等所佔的百分比

4.MYISAM和INNODB的鎖定 
myisam中，注意是表鎖來的，比如在多個UPDATE操作後，再SELECT時，會發現SELECT操作被鎖定了，必須等所有UPDATE操作完畢後，再能SELECT
innodb的話則不同了，用的是行鎖，不存在上面問題。 

5.MYSQL的事務配置項 
innodb_flush_log_at_trx_commit=1 
表示事務提交時立即把事務日誌flush寫入磁碟，同時資料和索引也更新，很費效能。
innodb_flush_log_at_trx_commit=0 
事務提交時，不立即把事務日誌寫入磁碟，每隔1秒寫一次，MySQL掛了可能會丟失事務的資料。
innodb_flush_log_at_trx_commit=2 ，在整個作業系統 掛了時才可能丟資料，一般不會丟失超過1-2秒的更新。
事務提交時，立即寫入磁碟檔案（這裡只是寫入到系統核心緩衝區，但不立即重新整理到磁碟，而是每隔1秒重新整理到磁碟，同時更新資料和索引），這種方案是不是價效比好一些，當然如何配置，決定於你對系統資料安全性的要求。

使用explain關鍵字可以模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的，分析你的查詢語句或是表結構的效能瓶頸。

explain執行計劃包含的資訊

其中最重要的欄位為：id、type、key、rows、Extra

各欄位詳解

id

select查詢的序列號，包含一組數字，表示查詢中執行select子句或操作表的順序 
三種情況： 
1、id相同：執行順序由上至下 

2、id不同：如果是子查詢，id的序號會遞增，id值越大優先順序越高，越先被執行 

3、id相同又不同（兩種情況同時存在）：id如果相同，可以認為是一組，從上往下順序執行；在所有組中，id值越大，優先順序越高，越先執行 

select_type

查詢的型別，主要是用於區分普通查詢、聯合查詢、子查詢等複雜的查詢

1、SIMPLE：簡單的select查詢，查詢中不包含子查詢或者union 
2、PRIMARY：查詢中包含任何複雜的子部分，最外層查詢則被標記為primary 
3、SUBQUERY：在select 或 where列表中包含了子查詢 
4、DERIVED：在from列表中包含的子查詢被標記為derived（衍生），mysql或遞迴執行這些子查詢，把結果放在零時表裡 
5、UNION：若第二個select出現在union之後，則被標記為union；若union包含在from子句的子查詢中，外層select將被標記為derived 
6、UNION RESULT：從union表獲取結果的select 

type

訪問型別，sql查詢優化中一個很重要的指標，結果值從好到壞依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般來說，好的sql查詢至少達到range級別，最好能達到ref

1、system：表只有一行記錄（等於系統表），這是const型別的特例，平時不會出現，可以忽略不計

2、const：表示通過索引一次就找到了，const用於比較primary key 或者 unique索引。因為只需匹配一行資料，所有很快。如果將主鍵置於where列表中，mysql就能將該查詢轉換為一個const 

3、eq_ref：唯一性索引掃描，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵 或 唯一索引掃描。 

注意：ALL全表掃描的表記錄最少的表如t1表

4、ref：非唯一性索引掃描，返回匹配某個單獨值的所有行。本質是也是一種索引訪問，它返回所有匹配某個單獨值的行，然而他可能會找到多個符合條件的行，所以它應該屬於查詢和掃描的混合體 

5、range：只檢索給定範圍的行，使用一個索引來選擇行。key列顯示使用了那個索引。一般就是在where語句中出現了bettween、<、>、in等的查詢。這種索引列上的範圍掃描比全索引掃描要好。只需要開始於某個點，結束於另一個點，不用掃描全部索引 

6、index：Full Index Scan，index與ALL區別為index型別只遍歷索引樹。這通常為ALL塊，應為索引檔案通常比資料檔案小。（Index與ALL雖然都是讀全表，但index是從索引中讀取，而ALL是從硬碟讀取） 

7、ALL：Full Table Scan，遍歷全表以找到匹配的行 

possible_keys

查詢涉及到的欄位上存在索引，則該索引將被列出，但不一定被查詢實際使用

key

實際使用的索引，如果為NULL，則沒有使用索引。 
查詢中如果使用了覆蓋索引，則該索引僅出現在key列表中 

key_len

表示索引中使用的位元組數，查詢中使用的索引的長度（最大可能長度），並非實際使用長度，理論上長度越短越好。key_len是根據表定義計算而得的，不是通過表內檢索出的

ref

顯示索引的那一列被使用了，如果可能，是一個常量const。

rows

根據表統計資訊及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數

Extra

不適合在其他欄位中顯示，但是十分重要的額外資訊

1、Using filesort ： 
mysql對資料使用一個外部的索引排序，而不是按照表內的索引進行排序讀取。也就是說mysql無法利用索引完成的排序操作成為“檔案排序” 

由於索引是先按email排序、再按address排序，所以查詢時如果直接按address排序，索引就不能滿足要求了，mysql內部必須再實現一次“檔案排序”

2、Using temporary： 
使用臨時表儲存中間結果，也就是說mysql在對查詢結果排序時使用了臨時表，常見於order by 和 group by 

3、Using index： 
表示相應的select操作中使用了覆蓋索引（Covering Index），避免了訪問表的資料行，效率高 
如果同時出現Using where，表明索引被用來執行索引鍵值的查詢（參考上圖） 
如果沒用同時出現Using where，表明索引用來讀取資料而非執行查詢動作 

覆蓋索引（Covering Index）：也叫索引覆蓋。就是select列表中的欄位，只用從索引中就能獲取，不必根據索引再次讀取資料檔案，換句話說查詢列要被所建的索引覆蓋。 
注意： 
a、如需使用覆蓋索引，select列表中的欄位只取出需要的列，不要使用select * 
b、如果將所有欄位都建索引會導致索引檔案過大，反而降低crud效能

4、Using where ： 
使用了where過濾

5、Using join buffer ： 
使用了連結快取

6、Impossible WHERE： 
where子句的值總是false，不能用來獲取任何元祖 

7、select tables optimized away： 
在沒有group by子句的情況下，基於索引優化MIN/MAX操作或者對於MyISAM儲存引擎優化COUNT（*）操作，不必等到執行階段在進行計算，查詢執行計劃生成的階段即可完成優化

8、distinct： 
優化distinct操作，在找到第一個匹配的元祖後即停止找同樣值得動作

綜合Case

執行順序 
1（id = 4）、【select id, name from t2】：select_type 為union，說明id=4的select是union裡面的第二個select。

2（id = 3）、【select id, name from t1 where address = ‘11’】：因為是在from語句中包含的子查詢所以被標記為DERIVED（衍生），where address = ‘11’ 通過複合索引idx_name_email_address就能檢索到，所以type為index。

3（id = 2）、【select id from t3】：因為是在select中包含的子查詢所以被標記為SUBQUERY。

4（id = 1）、【select d1.name, … d2 from … d1】：select_type為PRIMARY表示該查詢為最外層查詢，table列被標記為 “derived3”表示查詢結果來自於一個衍生表（id = 3 的select結果）。

5（id = NULL）、【 … union … 】：代表從union的臨時表中讀取行的階段，table列的 “union 1, 4”表示用id=1 和 id=4 的select結果進行union操作。

原文連結

1.使用explain語句去檢視分析結果 
如explain select * from test1 where id=1;會出現：id selecttype table type possible_keys key key_len ref rows extra各列。

其中， 
type=const表示通過索引一次就找到了； 
key=primary的話，表示使用了主鍵； 
type=all,表示為全表掃描； 
key=null表示沒用到索引。

type=ref，因為這時認為是多個匹配行，在聯合查詢中，一般為REF。

2.MYSQL中的組合索引 
假設表有id,key1,key2,key3,把三者形成一個組合索引，則如： 
複製程式碼 程式碼如下:

1.   where key1=....
2.   where key1=1 and key2=2
3.   where key1=3 and key2=3 and key3=2

根據最左字首原則，這些都是可以使用索引的，如from test where key1=1 order by key3，用explain分析的話，只用到了normal_key索引，但只對where子句起作用，而後面的order by需要排序。

3.使用慢查詢分析（實用）
在my.ini中： 
long_query_time=1 
log-slow-queries=d:\mysql5\logs\mysqlslow.log 
把超過1秒的記錄在慢查詢日誌中 
可以用mysqlsla來分析之。也可以在mysqlreport中，有如 
DMS分別分析了select ,update,insert,delete,replace等所佔的百分比

4.MYISAM和INNODB的鎖定 
myisam中，注意是表鎖來的，比如在多個UPDATE操作後，再SELECT時，會發現SELECT操作被鎖定了，必須等所有UPDATE操作完畢後，再能SELECT
innodb的話則不同了，用的是行鎖，不存在上面問題。 

5.MYSQL的事務配置項 
innodb_flush_log_at_trx_commit=1 
表示事務提交時立即把事務日誌flush寫入磁碟，同時資料和索引也更新，很費效能。
innodb_flush_log_at_trx_commit=0 
事務提交時，不立即把事務日誌寫入磁碟，每隔1秒寫一次，MySQL掛了可能會丟失事務的資料。
innodb_flush_log_at_trx_commit=2 ，在整個作業系統 掛了時才可能丟資料，一般不會丟失超過1-2秒的更新。
事務提交時，立即寫入磁碟檔案（這裡只是寫入到系統核心緩衝區，但不立即重新整理到磁碟，而是每隔1秒重新整理到磁碟，同時更新資料和索引），這種方案是不是價效比好一些，當然如何配置，決定於你對系統資料安全性的要求。

使用explain關鍵字可以模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的，分析你的查詢語句或是表結構的效能瓶頸。

explain執行計劃包含的資訊

其中最重要的欄位為：id、type、key、rows、Extra

各欄位詳解

id

select查詢的序列號，包含一組數字，表示查詢中執行select子句或操作表的順序 
三種情況： 
1、id相同：執行順序由上至下 

2、id不同：如果是子查詢，id的序號會遞增，id值越大優先順序越高，越先被執行 

3、id相同又不同（兩種情況同時存在）：id如果相同，可以認為是一組，從上往下順序執行；在所有組中，id值越大，優先順序越高，越先執行 

select_type

查詢的型別，主要是用於區分普通查詢、聯合查詢、子查詢等複雜的查詢

1、SIMPLE：簡單的select查詢，查詢中不包含子查詢或者union 
2、PRIMARY：查詢中包含任何複雜的子部分，最外層查詢則被標記為primary 
3、SUBQUERY：在select 或 where列表中包含了子查詢 
4、DERIVED：在from列表中包含的子查詢被標記為derived（衍生），mysql或遞迴執行這些子查詢，把結果放在零時表裡 
5、UNION：若第二個select出現在union之後，則被標記為union；若union包含在from子句的子查詢中，外層select將被標記為derived 
6、UNION RESULT：從union表獲取結果的select 

type

訪問型別，sql查詢優化中一個很重要的指標，結果值從好到壞依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般來說，好的sql查詢至少達到range級別，最好能達到ref

1、system：表只有一行記錄（等於系統表），這是const型別的特例，平時不會出現，可以忽略不計

2、const：表示通過索引一次就找到了，const用於比較primary key 或者 unique索引。因為只需匹配一行資料，所有很快。如果將主鍵置於where列表中，mysql就能將該查詢轉換為一個const 

3、eq_ref：唯一性索引掃描，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵 或 唯一索引掃描。 

注意：ALL全表掃描的表記錄最少的表如t1表

4、ref：非唯一性索引掃描，返回匹配某個單獨值的所有行。本質是也是一種索引訪問，它返回所有匹配某個單獨值的行，然而他可能會找到多個符合條件的行，所以它應該屬於查詢和掃描的混合體 

5、range：只檢索給定範圍的行，使用一個索引來選擇行。key列顯示使用了那個索引。一般就是在where語句中出現了bettween、<、>、in等的查詢。這種索引列上的範圍掃描比全索引掃描要好。只需要開始於某個點，結束於另一個點，不用掃描全部索引 

6、index：Full Index Scan，index與ALL區別為index型別只遍歷索引樹。這通常為ALL塊，應為索引檔案通常比資料檔案小。（Index與ALL雖然都是讀全表，但index是從索引中讀取，而ALL是從硬碟讀取） 

7、ALL：Full Table Scan，遍歷全表以找到匹配的行 

possible_keys

查詢涉及到的欄位上存在索引，則該索引將被列出，但不一定被查詢實際使用

key

實際使用的索引，如果為NULL，則沒有使用索引。 
查詢中如果使用了覆蓋索引，則該索引僅出現在key列表中 

key_len

表示索引中使用的位元組數，查詢中使用的索引的長度（最大可能長度），並非實際使用長度，理論上長度越短越好。key_len是根據表定義計算而得的，不是通過表內檢索出的

ref

顯示索引的那一列被使用了，如果可能，是一個常量const。

rows

根據表統計資訊及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數

Extra

不適合在其他欄位中顯示，但是十分重要的額外資訊

1、Using filesort ： 
mysql對資料使用一個外部的索引排序，而不是按照表內的索引進行排序讀取。也就是說mysql無法利用索引完成的排序操作成為“檔案排序” 

由於索引是先按email排序、再按address排序，所以查詢時如果直接按address排序，索引就不能滿足要求了，mysql內部必須再實現一次“檔案排序”

2、Using temporary： 
使用臨時表儲存中間結果，也就是說mysql在對查詢結果排序時使用了臨時表，常見於order by 和 group by 

3、Using index： 
表示相應的select操作中使用了覆蓋索引（Covering Index），避免了訪問表的資料行，效率高 
如果同時出現Using where，表明索引被用來執行索引鍵值的查詢（參考上圖） 
如果沒用同時出現Using where，表明索引用來讀取資料而非執行查詢動作 

覆蓋索引（Covering Index）：也叫索引覆蓋。就是select列表中的欄位，只用從索引中就能獲取，不必根據索引再次讀取資料檔案，換句話說查詢列要被所建的索引覆蓋。 
注意： 
a、如需使用覆蓋索引，select列表中的欄位只取出需要的列，不要使用select * 
b、如果將所有欄位都建索引會導致索引檔案過大，反而降低crud效能

4、Using where ： 
使用了where過濾

5、Using join buffer ： 
使用了連結快取

6、Impossible WHERE： 
where子句的值總是false，不能用來獲取任何元祖 

7、select tables optimized away： 
在沒有group by子句的情況下，基於索引優化MIN/MAX操作或者對於MyISAM儲存引擎優化COUNT（*）操作，不必等到執行階段在進行計算，查詢執行計劃生成的階段即可完成優化

8、distinct： 
優化distinct操作，在找到第一個匹配的元祖後即停止找同樣值得動作

綜合Case

執行順序 
1（id = 4）、【select id, name from t2】：select_type 為union，說明id=4的select是union裡面的第二個select。

2（id = 3）、【select id, name from t1 where address = ‘11’】：因為是在from語句中包含的子查詢所以被標記為DERIVED（衍生），where address = ‘11’ 通過複合索引idx_name_email_address就能檢索到，所以type為index。

3（id = 2）、【select id from t3】：因為是在select中包含的子查詢所以被標記為SUBQUERY。

4（id = 1）、【select d1.name, … d2 from … d1】：select_type為PRIMARY表示該查詢為最外層查詢，table列被標記為 “derived3”表示查詢結果來自於一個衍生表（id = 3 的select結果）。

5（id = NULL）、【 … union … 】：代表從union的臨時表中讀取行的階段，table列的 “union 1, 4”表示用id=1 和 id=4 的select結果進行union操作。

原文連結