MySQL優化：使用慢查詢日誌定位效率較低的SQL語句

MySQL經過慢查詢日誌定位那些執行效率較低的SQL 語句，用--log-slow-queries[=file_name]選項啓動時，mysqld 會寫一個包含全部執行時間超過long_query_time 秒的SQL語句的日誌文件，經過查看這個日誌文件定位效率較低的SQL 。

慢查詢日誌在查詢結束之後才記錄，因此在應用反映執行效率出現問題的時候查詢慢查詢日誌並不能定位問題，可使用show processlist命令查看當前MySQL在進行的線程，包括線程的狀態、是否鎖表等，能夠實時地查看SQL 的執行狀況，同時對一些鎖表操做進行優化。

下面咱們舉例說明一下，如何經過慢查詢日誌定位執行效率低的SQL 語句：

開啓慢查詢日誌，配置樣例:

[mysqld]   log-slow-queries

在my.cnf 配置文件中增長上述配置項並重啓mysql服務，這時mysql慢查詢功能生效。慢查詢日誌將寫入參數DATADIR（數據目錄）指定的路徑下，默認文件名是host_name-slow.log 。

和錯誤日誌、查詢日誌同樣，慢查詢日誌記錄的格式也是純文本，能夠被直接讀取。下例中演示了慢查詢日誌的設置和讀取過程。

首先查詢一下 long_query_time 的值 。

mysql> show variables like 'long%';   +-----------------+-------+   | Variable_name | Value |   +-----------------+-------+   | long_query_time | 10 |   +-----------------+-------+   1 row in set (0.00 sec)

爲了方便測試，將修改慢查詢時間爲5秒。

mysql> set long_query_time=5;   Query OK, 0 rows affected (0.02 sec)

依次執行下面兩個查詢語句。

第一個查詢由於查詢時間低於5 秒而不會出如今慢查詢日誌中：

mysql> select count(*) from order2008;   +----------+   | count(*) |   +----------+   | 208 |   +----------+   1 row in set (0.00 sec)

第二個查詢由於查詢時間大於5 秒而應該出如今慢查詢日誌中：

mysql> select count(*) from t_user;   +----------+   | count(*) |   +----------+   | 6552961 |

查看慢查詢日誌。

[root@localhost mysql]# more localhost-slow.log   # Time: 081026 19:46:34   # User@Host: root[root] @ localhost []   # Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 6552961   select count(*) from t_user;

從上面日誌中，能夠發現查詢時間超過5 秒的SQL，而小於5秒的則沒有出如今此日誌中。

若是慢查詢日誌中記錄內容不少，可使用mysqldumpslow工具（MySQL客戶端安裝自帶）來對慢查詢日誌進行分類彙總。下例中對日誌文件mysql_master-slow.log進行了分類彙總，只顯示彙總後摘要結果：

[root@mysql_master mysql_data]#mysqldumpslow mysql_master-slow.log   Reading mysql slow query log from mysql_master-slow.log   Count: 2 Time=11.00s (22s) Lock=0.00s (0s) Rows=1.0 (2), root[root]@mysql_master   select count(N) from t_user;

對於 SQL 文本徹底一致，只是變量不一樣的語句，mysqldumpslow 將會自動視爲同一個語句進行統計，變量值用N來代替。這個統計結果將大大增長用戶閱讀慢查詢日誌的效率，並迅速定位系統的SQL 瓶頸。

注意：慢查詢日誌對於咱們發現應用中有性能問題的SQL頗有幫助，建議正常狀況下，打開此日誌並常常查看分析。