如何打开MySQL的慢查询日志记录

目录

打开MySQL的慢查询日志

打开MySQL的慢查询日志很简单,只需要在MySQL的配置文件里(windows系统是my.ini,linux系统是my.cnf)的[mysqld]下面加上如下代码:
MySQL5.6以下版本加如下代码:

slow_query_log
log-slow-queries=/data/wwwroot/log/mysql/slowQuery.log
long_query_time=2
log-queries-not-using-indexes
log-long-format # (如果设置了,所有没有使用索引的查询也将被记录)
log-slow-admin-statements

MySQL5.6以上版本加如下代码:

slow-query-log=1 # slow quere log的开关,当值为1的时候说明开启慢查询。
slow-query-log-file=/data/wwwroot/log/mysql/slowQuery.log
long-query-time=2
log-queries-not-using-indexes
log-slow-admin-statements

上面的配置打开了slow query日志,将会捕获了执行时间超过了2秒的查询,包括执行速度较慢的管理命令(比如OPTIMEZE TABLE),并且记录了没有使用索引的查询。这些SQL,都会被记录到log-slow-queries指定的文件/var/lib/mysql/slow-queries.log文件中。
log-slow-queries <slow_query_log_file>
设置日志所在位置,可以为空,系统会给一个缺省的文件host_name-slow.log,生成的日志就在mysql的data目录下你必须保证mysql server进程mysqld_safe进程用户对该文件有w权限。
long_query_time
如果query time超过了该值,则认为是较慢查询,并被记录下来。单位是秒,最小值是1,默认值是10秒。10秒对于大多数应用来讲,太长了。我们推荐从3秒开始, 依次减少,每次都找出最”昂贵”的10条SQL语句并且优化他们。日复一日,一步一步优化。一次性找出很多条SQL语句,对于优化来讲,意义并不大。
log-queries-not-using-indexes
MySQL会将没有使用索引的查询记录到slow query日志中。无论它执行有多快,查询语句没有使用索引,都会被记录。有的时候,有些没有使用引索的查询非常快(例如扫描很小的表),但也有可能导致服务器变慢,甚至还会使用大量的磁盘空间。
log-slow-admin-statements
一些管理指令,也会被记录。比如OPTIMEZE TABLE, ALTER TABLE等等。

查看关于慢查询的状态

第一步:查看关于慢查询的状态
执行如下SQL语句来查看mysql慢查询的状态
show variables like '%slow%';
执行结果会把是否开启慢查询、慢查询的秒数、慢查询日志等信息打印在屏幕上。
第二步:执行一次慢查询操作
其实想要执行一次有实际意义的慢查询比较困难,因为在自己测试的时候,就算查询有20万条数据的海量表,也只需要0.几秒。我们可以通过如下语句代替:
SELECT SLEEP(10);
第三步:查看慢查询的数量
通过如下sql语句,来查看一共执行过几次慢查询:
show global status like '%slow%';

查看日志文件

我们可以通过tail -f查看日志文件。
$tail -f /var/lib/mysql/slow-queries.log
# Time: 110107 16: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 ep_friends;

第一行,SQL查询执行的时间
第二行,执行SQL查询的连接信息
第三行记录了一些我们比较有用的信息
Query_time SQL执行的时间,越长则越慢
Lock_time 在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
Rows_sent 查询返回的行数
Rows_examined 查询检查的行数
Slow Query日志,虽然帮助你记录了那些执行过了的SQL语句。但它不是万能的,意义可能没有你想象的那么大。它只告诉了你哪些语句慢,但是为什么慢?具体 原因,还是需要你自己去分析,不断的调试。也许,你只需要换一条更有效的sql语句,也许你只需简单地增加一个索引,但也有可能你需要调整你应用程序的设 计方案。比如,上面那条语句是很明显,它检查了600多万行数据。不幸的是,并不是每条语句都这么明显。也许还有别的原因,比如:
*锁表了,导致查询处于等态状态。lock_time显示了查询等待锁被翻译的时间
*数据或索引没有被缓存。常见于第一次启动服务器或者服务器没有调优
*备份数据库,I/O变慢
*也许同时运行了其它的查询,减少了当前查询

所以,不要过于紧张日志文件某条记录,而应该理性地审记,找出真正的原因。如果经常出现的slow query需要特别注意。如果个别出现,则做一些常规检查即可。我们建议,统计并且形成基准报告,进行比较排除,比胡乱瞎撞有用。希望大家不要在这部分过于浪费时间与精力。
线上记录slow query

上文的配置需要重启mysql server进程mysqld才会生效。但是很多时候,尤其是产品运营环境,不希望每次修改都需要重新启动mysql服务器,也希望能在某些特定时间记 录。MySQL5.1给我们提供了更为灵活的运行时控制,使得你不必重新启动mysql服务器,也能选择性地记录或者不记录某些slow queries。

缺陷与审记

虽然记录了slow query能够帮助你优化产品。但是MySQL目前版本,还有几大蹩足的地方。
1.MySQL5.0版本, long_query_time时间粒度不够细,最小值为1秒。对于高并发性能的网页脚本而言,1秒出现的意义不大。即出现1秒的查询比较少。直到mysql5.1.21才提供更细粒度的long_query_time设定.
2.不能将服务器执行的所有查询记录到慢速日志中。虽然MySQL普通日志记录了所有查询,但是它们是解析查询之前就记录下来了。这意味着普通日志没办法包含诸如执行时间,锁表时间,检查行数等信息。
3.如果开启了log_queries_not_using_indexes选项,slow query日志会充满过多的垃圾日志记录,这些快且高效的全表扫描查询(表小)会冲掉真正有用的slow queries记录。比如select * from category这样的查询也会被记录下来。

通过microslow-patch补丁可使用更细的时间粒度,和记录所有执行过的sql语句。不过,使用这个补订不得不自己编译MySQL,出于稳定性考滤,我们推荐在开发测试环境,可以打上这个补丁,享受这个补丁带来的便利。在运营环境尽量不要这么做…

用工具来分析slow query日志

MySQL自带了mysqldumpslow工具用来分析slow query日志,除此之外,还有一些好用的开源工具。比如MyProfi、mysql-log-filter,当然还有mysqlsla

如果日志内容很多,用眼睛一条一条去看会累死,mysql自带了分析的工具,使用方法如下:
命令行下,进入mysql/bin目录,输入mysqldumpslow –help或--help可以看到这个工具的参数
mysqldumpslow -s c -t 20 host-slow.log
mysqldumpslow -s r -t 20 host-slow.log
上述命令可以看出访问次数最多的20个sql语句和返回记录集最多的20个sql。
mysqldumpslow -t 10 -s t -g “left join” host-slow.log
这个是按照时间返回前10条里面含有左连接的sql语句。

其它相关参数

注意:这些日文件在mysql重启的时候才会生成
#记录所有sql语句
log=E:/mysqllog/mysql.log

#记录数据库启动关闭信息,以及运行过程中产生的错误信息
log-error=E:/mysqllog/myerror.log

# 记录除select语句之外的所有sql语句到日志中,可以用来恢复数据文件
log-bin=E:/mysqllog/bin

#记录查询慢的sql语句
log-slow-queries=E:/mysqllog/slow.log

#慢查询时间
long_query_time=0.5

参考资料:
开启mysql慢查询日志,不重启数据库的方法:http://jjdoor.blog.163.com/blog/static/18478034201282634426306/
动态开启慢查询日志:http://www.ningoo.net/html/2008/mysql_51_new_feather_1_log_output.html
mysql 开启慢查询日志:http://blog.csdn.net/showwair/article/details/7529874

发表评论?

0 条评论。

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据