mysql连接数飙升_玩转processlist，高效追溯MySQL活跃连接数飙升根因

一、引言

在运维MySQL时，经常遇到的一个问题就是活跃连接数飙升。一旦遇到这样的问题，都根据后台保存的processlist信息，或者连上MySQL环境，分析MySQL的连接情况。处理类似的故障多了，就萌生了一种想法，做个小工具，每次接到这种报警的时候，能够快速地从各个维度去分析和统计当前MySQL中的连接状态。比如当前连接的分布情况、活跃情况等等。

另外，真实故障处理时，光知道连接分布情况往往还不够，我们需要知道当前MySQL的正在忙于做什么，也就是正在执行一些什么样的SQL。而且，有时候即使我们知道了当前执行的SQL情况，也很难找到根因，因为如果活跃连接一旦飙升，这是的CPU基本上是处于被打满的状态，IO的负载也非常高，即使平时很快的SQL也变成了慢SQL，更不用说本身就很慢的SQL了。那我们怎么去甄别这些SQL里，哪些是导致问题的罪魁祸首，哪些仅仅是受害者呢？

带着这些需求和问题，本文逐渐展开并一一做分析和解答，展示我们这个小工具的功能。

二、连接分析

想知道当前MySQL的连接信息，最直观的方法是看MySQL的processlist，如果希望看到完整的SQL，可以执行show full processlist，或者直接查information_schema中的processlist这个表。当MySQL中连接数比较少的时候，还能够人肉分析出来，可是如果连接数比较多，那就很难考肉眼看processlist去分析问题了。

最开始，我们的做法是写个脚本，用MySQL客户端在命令行登录MySQL，并执行show full processlist，然后将输出作为一个文本分析。本来这种实现方式在MySQL5.5和MariaDB上运行得很好，可是，当在MySQL5.6环境上运行时，出现了问题，在控制台输出中会多出一行Warning: Using a password on the commandline interface can be insecure，相信很多运行orzdba的同学也遇到过这种情况。这个是MySQL5.6本身的安全提示，输入明文密码时，没有办法避免，阿里的同学还分享过他们为此做过源码改造，因为他们很多任务都依赖于命令行执行MySQL命令并捕获结果。

还有另外一种方式规避这个问题就是用mysql_config_editor这个工具，但是这个需要做额外的一些配置，同时也有安全上的隐患。我们没有能力改造源码，但是也不想使用mysql_config_editor，所以我们使用了另外的方式，不从命令行登录，而是用information_schema的表processlist作为数据源，在上面做查询，得到processlist的信息。还有另外一张表performance_schema.threads，也包含了同样的结果，甚至更丰富的后台线程信息，而且相比information_schema.processl