MySQL Threads_running飙升与慢查询的相关问题解决

背景

年前本应该是回顾一年工作和收尾的阶段，奈何各种促销，活动都等着春节，因此也遇到了不少的问题，回顾了一下最近遇到的问题，发现有好几个问题比较类似，正好整理一下，作为年前收尾的案例吧。表现上都是数据库假死，无响应，发生的场景有较高的业务压力到来时，也有业务正常运行的时候，突然就出现问题了。

问题描述

由于腾讯云数据库 MySQL 本身是有故障检测和高可用机制的，这几例问题发生的时候，从用户反馈的问题出现的时间点到实际介入排查的时候已经有好几分钟了，但是并没有触发高可用切换，说明这个问题可能并不是数据库自身的故障，也不是一些外部原因导致数据库不可用。

检查一下数据库当时候的状态，发现一个很不正常的指标：

MySQL Threads_running飙升与慢查询的相关问题解决

在问题的时间点附近，连接数的总数量和 threads_running 的数量在短时间内开始飙升，并且接近半分钟的时间内，连监控插件都采集不到数据了。在相同的时间段内，CPU 的使用率（达到 100%）、慢查询数量也跟着飙升。基本上可以确认 CPU 使用率，慢查询，连接数的指标这三者应该是相关联的，可以从这三者入手来分析这次问题的起因。

原因分析

99%的情况下，只要慢查询数量在飙升，那么这个问题就和慢查询脱不了关系，但是案例分析并不能这么草率的下结论。言归正传，既然目标缩小在三个指标上，那么分别考虑一下这三个指标的意义，看看这几个指标的异常会带来什么问题。

CPU

CPU 过高说明 MySQL 的计算能力被占满了，能占用 MySQL 计算资源的只有用户线程和 MySQL 自身的系统线程，这次问题明显和 MySQL 系统线程没什么关系，说明用户线程在大量占用 CPU 的计算资源，而且使用率达到 100% 说明有这个资源争抢的程度是非常严重的，可能会导致原本效率极高的查询因为拿不到 CPU 资源而变得非常缓慢，从高效率的查询变成低效的慢查询，从而产生数据库假死或者 hang 死的现象。

慢查询

慢查询是个老生常谈的问题了，因为查询效率过低，会过度占用 CPU，IO，内存等资源，从而影响到其他正常的查询，从监控指标上来说，CPU 使用率，IO 使用情况，内存使用率都可能会有不同程度的上升，严重的情况下也会引发这几个指标的飙升，导致整个数据库响应缓慢。

连接数

连接数通常是一个引发“实际故障”的指标，例如连接数达到 max_connections 的上限，从而导致整个数据库无法新建连接，程序侧直接是报错的，而不是无响应。threads_running 这个指标，参考官方文档的描述：

The number of threads that are not sleeping.

简单直白的解释，这个指标的飙升代表当时候有大量活跃的用户连接在 MySQL 实例中。而且从这个案例的监控图表来看，是一个飙升的趋势，说明是在短时间内出现了大量的活跃连接。

分析

完成这三个指标的简单分析，可以发现这个三个指标是互相影响：

慢查询堆积会导致 CPU 使用率过高；
CPU 过高会导致整体的查询效率变低，进而导致一些高效的查询变成慢查询；
慢查询的执行效率过低，会较长时间的保持活跃状态，所以 Threads_running 这个指标一定会上涨。
过高的并发突然到来时，大量的查询处于活跃状态会让 Threads_running 这个指标飙升，同时这种尖刺型的高峰也很容易占满 CPU。

看起来三个指标飙升的原因是自洽的，只靠这三个指标并不能真正的判断出问题的原因。那么仔细考虑一下这几个指标飙升的原因为什么会自洽？会发现有一个核心现象，或者说是共性：查询要能够堆积起来。如果：

堆积起来的查询本来效率就不高，那么这个问题的诱因基本就是慢查询了。
堆积起来的查询效率很高，那么这个问题的诱因可能是瞬间并发过高，或者是其他的原因导致 CPU 使用率暴涨，然后反过来影响了这些效率很高的查询。

所以检查一下堆积起来的查询，就能比较直白的分辨出问题了，就上图展示的这个案例而言，堆积起来的查询大量使用了 group by 和 order by，查询的效率比较低，所以根因还是慢查询。

拓展一下

如开篇所提及，最近发生的问题有多起，且原因类似。除了这个飙升的案例，还有如下所示的现象。

MySQL Threads_running飙升与慢查询的相关问题解决

threads_running 保持在一个相对平稳的数值，参考前文的分析，可以发现这个现象代表着在平时的时候，就有约 10 个查询长时间处于活跃状态，可以预测一个故障场景：业务量继续上升，活跃的查询变多，当高效的查询受影响，效率降低到一定程度的时候，前端程序/用户会因为超时或者响应慢的原因，发起重试，然后因为查询效率降低，这个重试被反复触发，然后引发雪崩效应，慢慢拖垮数据库。

万幸的是多个类似现象的实例仅有一个出现了问题，就是预测的这个场景，其他的都及时优化掉了。