一个普通WEB站点的页面常常需要查询N条SQL语句后才能得出页面结果，当网站访问速度慢而前端做了大量优化工作以后，数据库瓶颈的查找也是WEB优化的一个重要部分。

MySQL中提供了一个慢查询的日志记录功能，可以把查询SQL语句时间大于多少秒的语句写入慢查询日志，日常维护中可以通过慢查询日志的记录信息快速准确地判断问题所在。

开启慢查询功能

log-slow-queries 慢查询日志文件路径

long_query_time 超过多少秒的查询就写入日志

打开my.cnf配置文件，加入以下代码：

保存退出，重启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日志，或者其它工具也可以，通过工具配合可以更好的分析。