一个查询正常情况下都非常快，却有几次非常不合理的执行了很长时间，手工重新执行一遍，发现也非常快，可能是什么原因呢？？
可能是系统中有其他东西消耗了资源，比如正在备份，也有可能是某种类型的锁或者争用阻塞了查询的进度（间歇性问题）
2.单条查询问题还是服务器问题
如果服务器上所有程序都突然变慢，又突然都变好，每一条查询也都变慢了，那么慢查询可能就不一定是原因，而是由于其他问题
导致的结果。反过来说，如果服务器整体运行没有问题，只有某条查询偶尔变慢，就需要将注意力放到这条特定的查询上面。
2.1 使用SHOW GLOBAL STATUS
以较高的频率循环执行show global status 命令捕获数据，问题出现里，则可以通过某些计数器的值琰发现问题
mysqladmin ext -i1 | awk '/Queries/{q=$4-qp;qp=$4}/Threads_connected/{tc=$4}/Threads_running/{printf "%5d %5d %5d\n",q,tc,$4}'
循环1秒输出每秒查询数、Threads_connected,Threads_running。这三个数据的趋势对于服务器级别偶尔停顿的敏感性很高。一般发
发此类问题里，根据原因的不同和应用连接数据方式的不同，每次的查询数一般会下跌，而其他两个则至少有一个会出现尖刺。
2.2 使用SHOW PROCESSLIST
不停捕获输出，来观察是否有大量线程处于不正常的状态或者有其他不正常的特征。例如查询很少会长时间处于“statistics”状态。
大量线程处理“freeing items”状态是出现了大量有问题查询的很明显的特征的指示
mysql -e 'SHOW PROCESSLIST\G' | grep State: | sort | uniq -c | sort -rn
以上例子的输出可以看到，有很多线程处于查询执行的结束部份的状态，包括‘freeing items’ 、‘end’、‘cleaning up’和‘logging slow query’，同样的或类型的输出
采样出了很多次。这个例子是由于服务器InnoDB内部的争用和脏块刷新所导致，但有时候原因简单得多。一个典型的例子是很多查询处于
“Locked”状态，表级别锁定在写请求较多里，可能迅速导致服务器级别的线程堆积
2.3 使用查询日志
需要开启慢查询日志并在全局级别设置long_query_time为0。注意找到吞吐量突然下降时间段内的日志。查询是在完成阶段才写入到慢查询日志的，所以堆积会造成大量查询处理完成阶段，直到阻塞其他查询的资源占用者释放资料后，其他的查询才能执行完成。这种行为特征的一个好处是，当遇到吞吐量突然下隆里，可以归咎于吞吐量下隆后完成的第一个查询（有时候也不一定是第一个查询）
好的工具可以帮助诊断这类问题，以下例子只有一行代码，却可以根据MySQL每秒将当前时间写入日志中的模式统计每次的查询数量：
awk '^# Time:/{print $3,$4,c;c=0}/^# User/{c++}’ slow-query.log
从上面的输出可以看到有吞吐量突然下降的情况发生，而且在下降这前还有一个突然的高峰，这种现象很奇怪，值得去日志中挖掘该时间段的详细信息