MySql性能加速分析以及PHPMYADMIN中explain用法

如今和你們分享下如何對MySql性能加速分析以及PHPMYADMIN中explain用法的分析。

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,由於這時認爲是多個匹配行，在聯合查詢中，通常爲REF2 MYSQL中的組合索引
假設表有id,key1,key2,key3,把三者造成一個組合索引，則
如：
  where key1=….
  where key1=1 and key2=2
  where key1=3 and key3=3 and key2=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
表示事務提交時當即把事務日誌寫入磁盤，同時數據和索引也更新innodb_flush_log_at_trx_commit=0
事務提交時，不當即把事務日誌寫入磁盤，每隔1秒寫一次
innodb_flush_log_at_trx_commit=2
事務提交時，當即寫入磁盤文件（這裏只是寫入到內核緩衝區，但不當即刷新到磁盤，而是每隔1秒刷新到盤，同時更新數據和索引

explain用法

EXPLAIN tbl_name
或：
EXPLAIN [EXTENDED] SELECT select_options

前者能夠得出一個表的字段結構等等，後者主要是給出相關的一些索引信息，而今天要講述的重點是後者。

舉例
mysql> explain select * from event;
+—-+————-+——-+——+—————+——+———+——+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——+—————+——+———+——+——+——-+
| 1 | SIMPLE | event | ALL | NULL | NULL | NULL | NULL | 13 | |
+—-+————-+——-+——+—————+——+———+——+——+——-+
1 row in set (0.00 sec)

各個屬性的含義
id
select查詢的序列號

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

table
輸出的行所引用的表。

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

possible_keys
指出MySQL能使用哪一個索引在該表中找到行。若是是空的，沒有相關的索引。這時要提升性能，可經過檢驗WHERE子句，看是否引用某些字段，或者檢查字段不是適合索引。

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

key_len
顯示MySQL決定使用的鍵長度。若是鍵是NULL，長度就是NULL。文檔提示特別注意這個值能夠得出一個多重主鍵裏mysql實際使用了哪一部分。

ref
顯示哪一個字段或常數與key一塊兒被使用。

rows
這個數表示mysql要遍歷多少數據才能找到，在innodb上是不許確的。

Extra
若是是Only index，這意味着信息只用索引樹中的信息檢索出的，這比掃描整個表要快。
若是是where used，就是使用上了where限制。
若是是impossible where 表示用不着where，通常就是沒查出來啥。
若是此信息顯示Using filesort或者Using temporary的話會很吃力，WHERE和ORDER BY的索引常常沒法兼顧，若是按照WHERE來肯定索引，那麼在ORDER BY時，就必然會引發Using filesort，這就要看是先過濾再排序划算，仍是先排序再過濾划算。

常見的一些名詞解釋
Using filesort
MySQL須要額外的一次傳遞，以找出如何按排序順序檢索行。

Using index
從只使用索引樹中的信息而不須要進一步搜索讀取實際的行來檢索表中的列信息。

Using temporary
爲了解決查詢，MySQL須要建立一個臨時表來容納結果。

ref
對於每一個來自於前面的表的行組合，全部有匹配索引值的行將從這張表中讀取

ALL
徹底沒有索引的狀況，性能很是地差勁。

index
與ALL相同，除了只有索引樹被掃描。這一般比ALL快，由於索引文件一般比數據文件小。

SIMPLE
簡單SELECT(不使用UNION或子查詢)

 結束

轉自： MySql性能加速分析以及PHPMYADMIN中explain用法