在實際的日志分析中，通常慢日志的log數量不少，同時相同的查詢被記錄的條數也會很多，這裡就需要如何從慢日志查詢中找到最有問題，最需要優化的日志。在這方面，有很多分析工具，最基本的分析工具就是MySQL自帶的mysqldumpslow，mysqldumpslow(Perl腳本)的輸出示例：
[root@cloudlu bin]# ./mysqldumpslow -s t -t 1 /usr/local/mysql/data/cloudlu-slow.log Reading mysql slow query log from /usr/local/mysql/data/cloudlu-slow.log Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=3.0 (3), root[root]@localhost select * from t一看就非常清楚，它的輸出主要 統計不同慢sql的出現次數(Count 1)，執行最長時間(Time 0.00s)，累計總耗費時間(Time 0s)，等待鎖的時間(Lock 0.00s)，等待鎖的總時間(Lock 0s)，發送給客戶端的行總數(Rows 3.0)，掃描的行總數(Rows 3)，用戶(root)以及sql語句本身。它最常用的參數包括：
-s 排序選項：c 查詢次數 r 返回記錄行數 t 查詢時間
-t n：顯示top n條查詢
對於一般的分析已經差不多了，不過對於百分比等等數據mysqldumpslow就不夠完善了。所以世界上多了很多各種MySQL慢日志分析工具，比較優秀的有mysqlsla(Perl腳本)和pt-query-digest(Perl腳本)，可以提供Count, sql的執行次數及占總的slow log數量的百分比，Time, 執行時間, 包括總時間, 平均時間, 最小, 最大時間, 時間占到總慢sql時間的百分比，95% of Time, 去除最快和最慢的sql, 覆蓋率占95%的sql的執行時間，Lock Time, 等待鎖的時間，95% of Lock , 95%的慢sql等待鎖時間，Rows sent, 結果行統計數量, 包括平均, 最小, 最大數量，Rows examined, 掃描的行數量，還可以生成表報，存儲分析結果。這裡就不一一介紹了。
通過這些慢日志分析軟件定位到了慢查詢語句就已經完成了SQL優化的一大半。接下來通過在MySQL中執行explain或者desc命令查看慢查詢語句，可以看出為什麼SQL查詢慢。
mysql> explain select * from test.t \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2
Extra: NULL
1 row in set (0.00 sec)
它的輸出格式細節可以關注MySQL explain format，在輸出中最要注意的是：
1. type：ALL是效率最差，最要注意的
2. key：是否有使用Key，key長度如何
3. Extra：最好不要出現filesort以及temporary，最主要是要關注在orderby和groupby。
Note: SQL優化是個很復雜的過程，有可能出現拆東牆補西牆的情況：比如給數據庫表加入了索引之後，確實查詢快了，可是存儲空間加多了，插入刪除操作耗時也增加了，如果在一個寫多讀少的系統中，執行這種優化可能會起到反效果。所以優化完之後千萬不能大意，要持續監控系統，防止出現引入新瓶頸的情況。
