随着访问量的上升,MySQL数据库的压力就越大,几乎大部分使用MySQL架构的web应用在数据库上都会出现性能问题,通过mysql慢查询日志跟踪有问题的查询非常有用,可以分析出当前程序里有很耗费资源的sql语句。
慢查询日志我们可以通过my.cnf文件设置开启,下面先来看一下相关参数的意义
log-slow-queries <slow_query_log_file>
存放slow query日志的文件。你必须保证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
等等。
开启慢查询
方法一:在服务器上找到mysql的配置文件my.cnf , 然后再mysqld模块里追加一下内容
然后重启mysql服务器即可,这是通过一下命令看一下慢查询日志的情况:
方法二:通过修改myssql的全局变量来处理,这样做的好处是,不用重启mysql服务器,登陆到mysql上执行一下sql脚本即可
然后通过一下命令查看是否成功
分析慢查询日志
方法一:通过查看mysql的慢查询日志分析,比如我们可以tail -f slow_query.log查看里面的内容,字段意义
- 第一行,SQL查询执行的时间
- 第二行,执行SQL查询的连接信息
- 第三行记录了一些我们比较有用的信息
- Query_time SQL执行的时间,越长则越慢
- Lock_time 在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
- Rows_sent 查询返回的行数
- Rows_examined 查询检查的行数
方法二:使用mysqldumpslow命令分析,例如
这会输出记录次数最多的10条SQL语句,其中:
-s, 是表示按照何种方式排序,c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序,ac、at、al、ar,表示相应的倒叙; -t, 是top n的意思,即为返回前面多少条的数据; -g, 后边可以写一个正则匹配模式,大小写不敏感的;
比如
/path/mysqldumpslow -s r -t 10 /tmp/slow-log
得到返回记录集最多的10个查询。
/path/mysqldumpslow -s t -t 10 -g “left join” /tmp/slow-log
得到按照时间排序的前10条里面含有左连接的查询语句。
慢查询日志的不足
虽然记录了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
这样的查询也会被记录下来。开启了log_queries_not_using_indexes
选项,slow query日志会充满过多的垃圾日志记录,这些快且高效的全表扫描查询(表小)会冲掉真正有用的slow queries记录。比如select * from category
这样的查询也会被记录下来。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对服务器之家的支持。