MySQL慢查询的两种分析方案

日期: 2010-06-10 来源:TechTarget中国

  本文主要介绍的是MySQL慢查询分析方法,前一段日子,我曾经设置了一次记录在MySQL数据库中对慢于1秒钟的SQL语句进行查询。想起来有几个十分设置的方法,有几个参数的名称死活回忆不起来了,于是重新整理一下,自己做个笔记。

  对于排查问题找出性能瓶颈来说,最容易发现并解决的问题就是MySQL慢查询以及没有得用索引的查询。

  OK,开始找出MySQL中执行起来不“爽”的SQL语句吧。

  MySQL慢查询分析方法一:

  这个方法我正在用,呵呵,比较喜欢这种即时性的。

  MySQL5.0以上的版本可以支持将执行比较慢的SQL语句记录下来。

  MySQL> show variables like ‘long%’;

  注:这个long_query_time是用来定义慢于多少秒的才算“慢查询”

  +—————–+———–+

  | Variable_name | Value |

  +—————–+———–+

  | long_query_time | 10.000000 |

  +—————–+———–+

  1 row in set (0.00 sec)

  MySQL> set long_query_time=1;

  注: 我设置了1, 也就是执行时间超过1秒的都算慢查询。

  Query OK, 0 rows affected (0.00 sec)

  MySQL> show variables like ‘slow%’;

  +———————+—————+

  | Variable_name | Value |

  +———————+—————+

  | slow_launch_time | 2 |

  | slow_query_log | ON |

  注:是否打开日志记录

  | slow_query_log_file | /tmp/slow.log |

  注: 设置到什么位置

  +———————+—————+

  3 rows in set (0.00 sec)

  MySQL> set global slow_query_log=’ON’

  注:打开日志记录

  一旦slow_query_log变量被设置为ON,MySQL会立即开始记录。

  /etc/my.cnf 里面可以设置上面MySQL全局变量的初始值。

  long_query_time=1 slow_query_log_file=/tmp/slow.log

  MySQL慢查询分析方法二:

  MySQLdumpslow命令

  /path/MySQLdumpslow -s c -t 10 /tmp/slow-log

  这会输出记录次数最多的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条里面含有左连接的查询语句。

  以上的相关内容就是对MySQL慢查询分析的介绍,望你能有所收获。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐

  • Notre Dame对云端SQL Server性能基准的探索实践

    确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。

  • DBA必须掌握的数据库恢复管理技术

    如果没有备份副本,数据库管理员就无法还原数据库,所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是,对我来说,这种逻辑一直是错误的。

  • 表征数据库性能问题的三个指标

    即使数据库结构定义和SQL代码编写非常完美,应用程序性能都可能下降。如果性能问题不能得到及时纠正,那么就可能为公司带来很大的损失。

  • DBA也要和领导抢饭碗?

    数据库架构师Ziaul Mannan 认为,DBA有成为高管的潜在可能,而这种潜力在过去往往被忽视,他还将证明DBA技能到领导力的转变是可行的。