一次MySQL慢查询导致的故障

我们知道分析mysql语句查询性能的方法除了使用explain 输出执行计划，还可以让mysql记录下查询超过指定时间的语句，我们将超过指定时间的sql语句查询称为“慢查询”。

一、 起因
研发反应某台数据库僵死，后面的会话要么连接不上，要么要花费大量的时间返回结果，哪怕是一个简单的查询。

二、 处理
首先去监控平台查看服务器以及数据库状态，发现这台数据库有大量的慢查询。继续看服务器监控，cpu 平均使用率较高，io 读写平均值正常。登录到 mysql，使用 show processlist 查看会话状态，总数居然有 600+，这是很不正常的。查看慢查询日志，发现出问题的 sql 主要集中在几个，有 sum、有 count、有等值操作等等。这台 mysql 服务器的 long_query_time 设置为 3秒，而一个简单的查询却要几十秒，这显然是有问题的。写脚本试着 kill 掉相关的会话，发现于事无补，仍然有大量的连接进来。此时使用 top 查看服务器状态，mysqld 进程占用内存和 cpu 居高不下。

故障期间的慢查询数，如图：

cpu 平均使用率，如图：

接着使用 show full processlist 查看完整状态，在最上面居然发现几条 sql。这些 sql 操作使用子查询实现，time 列居然达到了 30000 秒，折算过来差不多 10 小时。explain 这些语句，居然出现了 using tempory 和 using filesort，可以看出这些语句是很糟糕的。于是跟开发确认，紧急把这些会话 kill 掉。稍等片刻，会话数立马降下来，只有 100+，top 查看 mysqld 进程，内存和 cpu 都呈现下降的趋势。接着分析开发说上午 9 时写了这些 sql，发现有问题，注释掉了。新的代码虽然没有此类 sql，但之前建立的连接并不会释放。解决问题和出现问题的时间差刚好可以和添加子查询的时间对应，就可以确认子查询是此次故障的罪魁祸首。

三、 总结
通过这个故障，总结如下几点：

• mysql 应该尽量避免使用子查询，即使使用，也要搞清楚大表和小表的关系；
• 出现这类问题的排查步骤：

第一，查看服务器监控和 mysql 监控，分析服务器以及 mysql 性能，找出异常；
第二，如果是慢查询导致，查看慢查询日志，找出出现问题的 sql，试着优化，或者把结果缓存；
第三，分清主次，先解决大块问题，后解决细小问题。 把大块的异常解决，小问题就迎刃而解了。比如本文中的例子，把耗费时间长的会话 kill 掉后，后面的连接就正常了；
第四，总结分析。

• 高效的沟通会事半功倍；
• dba 需要定期给出 top n sql（类 oracle 的说法），提供给开发，并协助优化；
• 查看监控时，不管是服务器监控还是 mysql 监控，需要做对比，比如和昨天甚至前天的同一时间对比，这会更加快速地定位问题。

四、 技巧
最后，附上一个快速kill 掉 mysql 会话的方法：

首先使用如下语句分析出有问题的 sql：

/usr/local/mysql/bin/mysql -uroot -p'xxx' \ -e "show full processlist;" | more

然后将 show full processlist 的结果保存到一个文件：

/usr/local/mysql/bin/mysql -uroot -p'xxx' \
-e "show full processlist;" | \
grep "xxx" | awk '{print $1}' > mysql_slow.txt

最后使用如下简单的 shell 脚本 kill 掉相关会话：

select concat('kill ',id,';')
from information_schema.processlist
where info like 'xxx';

当然也可以使用如下 sql 拼接 kill 语句：

select concat('kill ',id,';')
from information_schema.processlist
where info like 'xxx';

本文对mysql慢查询导致故障的起因，处理方法，所需的技巧进行了全面分析，希望可以让大家更好的了解mysql慢查询，对大家的。