应用发版后 MySQL 响应变得非常慢

现象

上个周末想睡个懒觉的我被一通电话叫醒了，昨晚在现场通宵保障某大客户10月版应用发布的同事说一个应用后端的 MySQL 节点响应非常慢，show processlist 看到有1200+ 线程，基本都处于 running 状态，持续时间都达到几十秒，问我怎么办？

排查过程

作为一名乙方公司的DBA，考虑到是周日早上7点，先询问了一下客户爸爸现场的情况，得知甲方有人在现场主持大局后松了口气。接下来我让同事收集了几个信息：

1. top 输出信息里 cpu、io 负载情况；
2. "show full processlist;" 随便找一条查询语句，查看其执行计划，以及线程状态。

然后得到回复：

1. MySQL所在服务器 cpu 已经打满了，iowait 也很高；
2. 看了一条已经执行 30s+ 的查询，状态为 "sending data"，执行计划看到是走索引，扫描行数很小。

这说明 MySQL 里存在很多慢查询，所以导致系统资源使用很高。但是简单看了一条 SQL 的执行计划是没问题的，根据经验，并且结合前一天晚上应用发版，推测：
应用代码里新加了 SQL，或者做了表结构变更导致了部分 SQL 做全表扫描和排序等计算，大量消耗cpu、io资源，导致正常的 SQL 也运行缓慢。

如何验证这一推测呢？show processlist 输出有1000+ 线程，一个个看肯定不行。其实很简单，借助 slow log 及其分析工具 mysqldumpslow、pt-query-digest，分析故障发生以来的 slow log 中有没有扫描行数很多的 SQL。现场进行分析后发现确实有一个 update 语句进行了全表扫描，是应用新加的。定位到原因后顺利解决。

总结

由于客户的限制，日志啊状态啥的都没拿出来，以上的分析过程都没有贴出“证据”，分析思路在这里更重要。

另外将事后分析转变成事前规避也是相当重要的，这里很大一个问题是没有 SQL 审核环节，生产环境应用发起的全表扫描会造成很严重的后果！在我前面五年的职业生涯里成长最大的一个项目中，SQL下发和 SQL 审核做到了很好结合：应用提交需要审核的 SQL 文件和环境信息到审核平台，平台根据执行计划和一些规则判断是否通过，如果通过则直接执行了不需要通过 DBA 或者应用手工去执行，如果通不过则返回提示不执行。