一個普通WEB站點的頁面常常需要查詢N條SQL語句后才能得出頁面結果，當網站訪問速度慢而前端做了大量優化工作以后，數據庫瓶頸的查找也是WEB優化的一個重要部分。
MySQL中提供了一個慢查詢的日志記錄功能，可以把查詢SQL語句時間大于多少秒的語句寫入慢查詢日志，日常維護中可以通過慢查詢日志的記錄信息快速準確地判斷問題所在。
開啟慢查詢功能
log-slow-queries 慢查詢日志文件路徑
long_query_time 超過多少秒的查詢就寫入日志
打開my.cnf配置文件，加入以下代碼：
log-slow-queries = /tmp/mysql-slow.log
long_query_time = 2
如果是windows則在my.ini中加入
my.ini
log_slow_queries
long_query_time = 2
保存退出，重啟MySQL即可。
關于long_query_time設置
通常我們設置long_query_time的值為2，表示查詢SQL語句超過兩秒的就記錄，通常2秒就夠了，默認是10秒。然而，對于許多WEB程序來說，2秒的查詢還是太長了。的確在許多站點中，一個SQL語句超過1秒的執行時間都算慢的了。
mysql5.1.21以后才提供更細粒度的long_query_time設定，之前的版本只能以秒做單位。
查看日志
[root@lizhong tmp]# tail -f /tmp/mysql_slow.log
Time: 120815 23:22:11
User@Host: root[root] @ localhost []
Query_time: 9.869362 Lock_time: 0.000035 Rows_sent: 1 Rows_examined: 6261774
SET timestamp=1294388531;
select count(*) from blog;
第一行：執行時間
第二行：執行用戶
第三行（重要）：
Query_time SQL執行的時間,越長則越慢
Lock_time 在MySQL服務器階段(不是在存儲引擎階段)等待表鎖時間
Rows_sent 查詢返回的行數
Rows_examined 查詢檢查的行數
最后
1、日志不能說明一切問題，知識表象，可能跟鎖表、系統繁忙的偶發性有關，當然，如果某條SQL語句經常查詢慢那基本可以判斷是可以再次優化的。
2、不要開啟log-queries-not-using-indexes沒有索引查詢記錄功能，這個功能實際用處不大。就是記錄SQL查詢的時候，沒有索引的通通記錄。雖然索引對查詢的速度有影響，但要看數據量大小。因為開啟了這個功能以后，select * from tab這樣的查詢也會被記錄在日志中，很快日志文件就會被垃圾信息給充滿，從而影響主要的查詢慢日志記錄的查看。
3、MySQL自帶了mysqldumpslow工具用來分析slow query日志，或者其它工具也可以，通過工具配合可以更好的分析。
