5.3 识别慢速查询

li3p

　　找出哪些查询执行速度比较慢，通常要比找出它们慢的原因、并执行必要的修改以修复问题来得简单。最简单的跟踪耗时查询的方式莫过于让MySQL来替你跟踪。通过打开耗时查询日志（Slow Query Log），你可以告诉MySQL记录每条执行时间超过一定秒数的查询。除了查询语句以外，它还会记录一些其他元数据（Meta Data）。
　　这里有一个耗时索引日志的例子：
# Time: 030303  0:51:27# User@Host: user[user] @ client.example.com [192.168.50.12]# Query_time: 25  Lock_time: 0  Rows_sent: 3949  Rows_examined: 378036select ArticleHtmlFiles.SourceTag, ArticleHtmlFiles.AuxId from ArticleHtmlFiles left join Headlines on ArticleHtmlFiles.SourceTag = Headlines.SourceTag and ArticleHtmlFiles.AuxId = Headlines.AuxId where Headlines.AuxId is NULL;
　　尽管在日志中包含了很多有用的信息，但是却缺乏非常重要的一点信息：为什么这个查询会这么耗时。如果日志告诉你有12,000,000条记录被检查，并且1,200,00被发送回客户端，那么你无疑你就清楚耗时的原因了。但是事情极少这么一目了然。还有更糟糕的情况是，你或许发现了一个耗时查询，可是当你将查询语句复制到一个你常用的MySQL客户端中，你发现这个查询却能够以毫秒级的时间执行。
　　你一定要小心不要被耗时查询日志中过多的信息所干扰。当一个查询出现在此日志中，并非表示这就是一个不好的查询－或者就是一个耗时的查询。这只是意味着这个查询在执行的那一刻花了比较长的时间。但不意味着这个查询现在或者将来执行的时候一定也会花这么多时间。
　　关于为什么同一个查询在某一时刻比较慢，而其他时候却挺快的原因有很多：
·         表已经被锁住，导致查询必须要等待。Lock_time列标示查询等待锁被释放的时间。
·         所用到数据以及索引还没有在内存中进行缓存。在MySQL刚启动的时间或者没有被良好调优的情况下比较长剑。第四章里对此有更为详细的讨论。
·         一个每日自动备份进程正在运行，这导致所有的磁盘I/O操作相当缓慢。
·         服务器可能正在同时处理上百个互相没有任何关联的查询，与此同时CPU也没有足够的计算能力来进行有效的处理。
　　上面的清单还可以继续开列下去。说到底就是：耗时查询日志只是部分记录了发生了什么。你可以借助这些记录来生成可能的嫌疑列表，但你的确需要更加深入的调查每个查询语句。当然，如果你遇到在日志中看到同样的条目一次又一次的出现，这表示你的确是找到了一个真凶。
　　MySQL还提供了一个mysqldumpslow工具，这是一个可用来更有效的分析耗时查询日志并提供对每个耗时查询执行频度信息的Perl脚本。这样一来你就不用浪费精力去优化一个耗时30秒但每天才执行一次的查询，而忽略了有五个每次耗时两秒却每天要执行上千次的查询。
　　附录B中包含使用mytop工具来执行实时监控的信息，其中也包括慢速查询。

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/7114/showart_276525.html