本文我們主要介紹了MySQL效能分析以及explain的使用，包括：組合索引、慢查詢分析、MYISAM和INNODB的鎖定、MYSQL的事務配置項等，希望能夠對您有所幫助。

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用法詳解
EXPLAIN tbl_name或：EXPLAIN [EXTENDED] SELECT select_options
前者可以得出一個表的欄位結構等等，後者主要是給出相關的一些索引資訊，而今天要講述的重點是後者。
舉例

1. mysql> explain select * from event;   
2. +—-+————-+——-+——+—————+——+———+——+——+——-+   
3. | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |   
4. +—-+————-+——-+——+—————+——+———+——+——+——-+   
5. | 1 | SIMPLE | event | ALL | NULL | NULL | NULL | NULL | 13 | |   
6. +—-+————-+——-+——+—————+——+———+——+——+——-+   
7. 1 row inset (0.00 sec)   

各個屬性的含義

id :select查詢的序列號

select_type:select查詢的型別，主要是區別普通查詢和聯合查詢、子查詢之類的複雜查詢。

a.SIMPLE：查詢中不包含子查詢或者UNION b.查詢中若包含任何複雜的子部分，最外層查詢則被標記為：PRIMARY c.在SELECT或WHERE列表中包含了子查詢，該子查詢被標記為：SUBQUERY d.在FROM列表中包含的子查詢被標記為：DERIVED（衍生） e.若第二個SELECT出現在UNION之後，則被標記為UNION；若UNION包含在 FROM子句的子查詢中，外層SELECT將被標記為：DERIVED f.從UNION表獲取結果的SELECT被標記為：UNION RESULT

table :輸出的行所引用的表。

type :聯合查詢所使用的型別，表示MySQL在表中找到所需行的方式，又稱“訪問型別”。

type顯示的是訪問型別，是較為重要的一個指標，結果值從好到壞依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ，一般來說，得保證查詢至少達到range級別，最好能達到ref。

ALL: 掃描全表
index: 掃描全部索引樹
range: 掃描部分索引，索引範圍掃描，對索引的掃描開始於某一點，返回匹配值域的行，常見於between、<、>等的查詢
ref: 非唯一性索引掃描，返回匹配某個單獨值的所有行。常見於使用非唯一索引即唯一索引的非唯一字首進行的查詢

eq_ref：唯一性索引掃描，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵或唯一索引掃描
const, system: 當MySQL對查詢某部分進行優化，並轉換為一個常量時，使用這些型別訪問。如將主鍵置於where列表中，MySQL就能將該查詢轉換為一個常量。system是const型別的特例，當查詢的表只有一行的情況下， 使用system。
NULL: MySQL在優化過程中分解語句，執行時甚至不用訪問表或索引。

如下所示：

possible_keys:指出MySQL能使用哪個索引在該表中找到行。查詢涉及到的欄位上若存在索引，則該索引將被列出，但不一定被查詢使用。如果是空的，沒有相關的索引。這時要提高效能，可通過檢驗WHERE子句，看是否引用某些欄位，或者檢查欄位不是適合索引。 
 

key :顯示MySQL實際決定使用的鍵。如果沒有索引被選擇，鍵是NULL。

key_len:顯示MySQL決定使用的鍵長度。表示索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度。如果鍵是NULL，長度就是NULL。文件提示特別注意這個值可以得出一個多重主鍵裡mysql實際使用了哪一部分。

 注：key_len顯示的值為索引欄位的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的。

ref:顯示哪個欄位或常數與key一起被使用。

rows:這個數表示mysql要遍歷多少資料才能找到，表示MySQL根據表統計資訊及索引選用情況，估算的找到所需的記錄所需要讀取的行數，在innodb上可能是不準確的。

Extra:包含不適合在其他列中顯示但十分重要的額外資訊。

Only index，這意味著資訊只用索引樹中的資訊檢索出的，這比掃描整個表要快。 

using where是使用上了where限制，表示MySQL伺服器在儲存引擎受到記錄後進行“後過濾”（Post-filter），如果查詢未能使用索引，Using where的作用只是提醒我們MySQL將用where子句來過濾結果集。

impossible where 表示用不著where，一般就是沒查出來啥。 

Using filesort（MySQL中無法利用索引完成的排序操作稱為“檔案排序”）當我們試圖對一個沒有索引的欄位進行排序時，就是filesoft。它跟檔案沒有任何關係，實際上是內部的一個快速排序。 

Using temporary（表示MySQL需要使用臨時表來儲存結果集，常見於排序和分組查詢），使用filesort和temporary的話會很吃力，WHERE和ORDER BY的索引經常無法兼顧，如果按照WHERE來確定索引，那麼在ORDER BY時，就必然會引起Using filesort，這就要看是先過濾再排序划算，還是先排序再過濾划算。

最後，再看一個查詢計劃的例子：

第一行：id列為1，表示第一個select，select_type列的primary表示該查詢為外層查詢，table列被標記為<derived3>，表示查詢結果來自一個衍生表，其中3代表該查詢衍生自第三個select查詢，即id為3的select。[select d1.name......]
第二行：id為3，表示該查詢的執行次序為2（4→3），是整個查詢中第三個select的一部分。因查詢包含在from中，所以為derived。[select id,name from t1 where other_column='']
第三行：select列表中的子查詢，select_type為subquery，為整個查詢中的第二個select。[select id from t3]
第四行：select_type為union，說明第四個select是union裡的第二個select，最先執行。[select name,id from t2]
第五行：代表從union的臨時表中讀取行的階段，table列的<union1,4>表示用第一個和第四個select的結果進行union操作。[兩個結果union操作]

關於MySQL執行計劃的侷限性：

EXPLAIN不會告訴你關於觸發器、儲存過程的資訊或使用者自定義函式對查詢的影響情況
EXPLAIN不考慮各種Cache
EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作
部分統計資訊是估算的，並非精確值
EXPALIN只能解釋SELECT操作，其他操作要重寫為SELECT後檢視。

備註：

filesort是通過相應的排序演算法,將取得的資料在記憶體中進行排序。

MySQL需要將資料在記憶體中進行排序，所使用的記憶體區域也就是我們通過sort_buffer_size 系統變數所設定的排序區。這個排序區是每個Thread 獨享的，所以說可能在同一時刻在MySQL 中可能存在多個 sort buffer 記憶體區域。

在MySQL中filesort 的實現演算法實際上是有兩種：

雙路排序：是首先根據相應的條件取出相應的排序欄位和可以直接定位行資料的行指標資訊，然後在sort buffer 中進行排序。
單路排序：是一次性取出滿足條件行的所有欄位，然後在sort buffer中進行排序。

在MySQL4.1版本之前只有第一種排序演算法雙路排序，第二種演算法是從MySQL4.1開始的改進演算法，主要目的是為了減少第一次演算法中需要兩次訪問表資料的IO操作，將兩次變成了一次，但相應也會耗用更多的sortbuffer 空間。當然，MySQL4.1開始的以後所有版本同時也支援第一種演算法。
MySQL主要通過比較我們所設定的系統引數 max_length_for_sort_data的大小和Query 語句所取出的欄位型別大小總和來判定需要使用哪一種排序演算法。如果 max_length_for_sort_data更大，則使用第二種優化後的演算法，反之使用第一種演算法。所以如果希望 ORDER BY 操作的效率儘可能的高，一定要注意max_length_for_sort_data 引數的設定。如果filesort過程中，由於排序快取的大小不夠大，那麼就可能會導致臨時表的使用。

max_length_for_sort_data的預設值是1024。

• id：每個被獨立執行的操作的標識，表示物件被操作的順序；ID值大，先被執行；如果相同，執行順序一般從上到下。

• select_type: 資料庫引擎將SQL拆分成若干部分的子查詢/子操作，每個查詢select子句中的查詢型別（後文詳細講解）。

• table: 本次子查詢所查詢的目標資料表。SQL查詢語句即使再複雜，一次子查詢也只可能最多關聯一張資料表。

• partitions: 本次查詢所涉及的資料表目標分割槽資訊（如果有分割槽的話）。後文將對分割槽的概念進行概要說明。

• type: 子查詢型別，非常重要的效能衡量點。這個欄位項可能顯示的值包括：“ALL->index->range->ref->eq_ref->const | system->NULL”這些值所表示的查詢效能，從左至右依次增加（注意，按照資料庫基本思想——B+樹，查詢效能可能呈幾何級的變化也可能差異不大）。這些值所代表的查詢動作，在後文中會詳細進行介紹。

• possible_keys: 本次子查詢可能使用的索引（前提是，您要建立了索引）。如果查詢所使用的檢索條件可能涉及到多個索引，這裡將會列出這些所有的可能性。

• key: 本次子查詢最終被選定的執行索引。有的時候possible_keys可能有值，但keys可能沒有，這就代表InnoDB引擎最終並沒有使用任何索引作為檢所依據。

• key_len： 被選定的索引鍵的長度。

• ref: 表示本次子查詢參照的參照條件/參照資料表，參照條件/參照資料表，這個欄位的值還可能是一個常量。

• rows： 執行根據目前資料表的實際情況預估的，完成這個子查詢需要掃描的資料行數。

• Extra：包含不適合在其他列中顯示但十分重要的額外資訊。這個欄位所呈現的資訊在後文也會進行詳細說明。