小螞蟻學習mysql性能優化（3）--SQL以及索引優化--慢查日誌分析工具和explain說明

昨天在測試操做數據庫的時候碰到兩個問題忘了記錄下來，今天補充上去，接上篇

1. 安裝測試數據庫sakila時報錯。Mysql server has gone away的問題。解決方法：

查看    show global variables like 'max_allowed_packet';

通常來講會顯示    max_allowed_packet    1048576

修改成    set global max_allowed_packet=1024*1024*16;    

發生這種狀況的緣由，多是發送的sql語句太長，以致於超過了max_allowed_packet的大小，若是確認是這種緣由，只要修改my.cnf，加大max_allowed_packet的值便可。

2. 我用 mysql 版本   5.6.*  在設置long_query_time的時候，一直修改不了，不生效。在網上查詢了一下解釋，通過本身測試，這估計是個bug吧，其實已經修改爲功了。能夠另外打開一個mysql控制檯，再查看，就會顯示正確。

這是昨天碰到的兩個問題，在這裏補充一下。

慢查日誌的分析工具

mysqldumpslow  安裝mysql的時候系統自帶。最經常使用，可是功能不是很完善。

例子：mysqldumpslow -t 3 慢查日誌路徑 | more

分析慢查日誌最耗時的前三條。

pt_query_digest    推薦這一款比較完善的工具

examine 單詞 檢查  rows examine  掃描的行數

如何經過慢查日誌發現有問題的SQL？

1. 查詢次數多而且每次查詢佔用時間長的SQL，一般爲pt_query_digest分析的前幾個查詢。

2. IO大的SQL。注意pt_query_digest分析中的Rows examine項。

未命中索引的SQL。

注意pt_query_digest分析中的這兩項的對比    rows examine 和 rows send  掃描行數和發送行數

若是rows examine 遠遠大於rows send的話，說明未命中。

找到很是耗時sql以後，如何分析，使用explain，explain返回各列的含義

    table:    顯示這一行的數據時關於哪張表

    type:    重要列！！顯示了鏈接使用了何種類型。從最好到最差的鏈接類型爲const、eq_reg、reg、range、index    和 all。

    possible_keys:    顯示可能應用在這張表中的索引。若是爲空，沒有可能的索引。

    key：    實際使用的索引。若是爲null，則沒有使用索引。

    key_len:    使用的索引的長度。在不損失精確性的狀況下，長度越短越好

    ref:    顯示索引的哪個列被使用了，若是可能的話，是一個常數

    rows:    mysql認爲必須檢查的用來返回請求數據的行數

    extra:    須要注意的返回值（擴展列）

            using filesort : 看到這個的時候，查詢就須要優化。mysql須要進行額外的步驟來發現如何對返回的行排序。它根據連接類型以及存儲排序鍵值和匹配條件的所有行的行指針來排序所有行。

            using temporary : 看到這個的時候，查詢須要優化。mysql須要建立一個臨時表來存儲結果，這一般發生在對不一樣的列集進行order by上，而不是group by 上。