MySQL太慢？试试这些诊断思路和工具

如果能做得更好，你可以抽检自己的数据库然后做环比图，比如今天和昨天同样的时间，同样的业务压力下对数据库的延迟进行分析，如果数据库的延迟峰一直在往后延，就意味着数据库的状态在变得更糟糕一些。这是 bcc 第一个能做的事情，需要再次强调的是它开箱即用直接下载过来就可以使用。

MySQL 的慢查询：

MySQL 本身提供很好的慢查询，为什么还要用另外一个机制来获取 MySQL 的慢查询呢？

MySQL 的慢查询可能很难做，与 MySQL 的慢日志相比, 它可以低成本地完成:

• 获取少量慢查询
• 获取某种模式的慢查询
• 获取某个用户的慢查询

比如说获取少量的慢查询，为什么是少量呢？因为不确定现在的线上延迟是多少，慢查询只开一秒可能日志瞬间就被堆上去，性能就会下来，但是如果慢查询开个十秒左右，没有请求在这个区间命中，所以要一点一点的去调这个值，比如说线上 1% 的最慢的查询能够命中，但是在这个脚本里面，可以取一定区间的最大的几个查询把它拎出来。

通过脚本还可以命中某种模式的慢查询, 比如说我们只关心 update 的慢查询, 那么获取 select 的结果就没有太大的意义，或者是我一定要获取某一些特定表的相关的查询，我都可以通过脚本来做。

第三种情况，想获取某个用户的慢查询，这个一般对于多租户系统，因为多租户系统只想针对某一个用户进行慢查询分析的时候，这种脚本就比较好用。

VFS 延迟分析：

对 VFS 做延迟分析，这是对数据库进行了一个写压力，可以明显看到一个双峰图，这是写的两个峰，是数据库对于内核的写压力的反馈。

这个意味着什么呢？这个可能意味着因为这部分的写是命中了操作系统文件系统的缓存，而下面这部分写是真正的写穿到设备的，所以他们俩的延迟不一样，这是一个典型的双峰图，大家需要把两个峰拆开来去行这样的分析。

换一个说法，如果写压力都集中在这里，而没有第二个峰的情况下，需不需要去更换物理设备？有可能不需要，因为所有的东西都命中了操作系统的缓存。

短生命周期的临时文件检测：

这个不一定常见，MySQL 会在某些情况下动用临时表, 如果 SQL 没写好就会创建临时表，这些临时表的生命周期很短，但是量很大，所以一定要写文件而不能内存里。

在这种情况下会对操作系统造成一些压力，而这个压力又不太好诊断，因为临时文件的生存周期短，所以这个脚本可以帮大家提供一个方案，这个方案的结果是这样子。

我做了一个临时表，这个临时表活了 5.3 秒左右，于是它展现在了脚本的结果里。如果扫描自己的线上 MySQL 发现这里有大量的东西说明在大量的使用临时表，如果 IO 压力在此时比较大, 就可能受了临时表的影响。

短连接分析：

好一点的应用都会用连接池，但是我们很多的时候没有那么好的运气，老碰到那么好的应用，所以经常业务会扔过来大量的短连接。

这个例子中, sysbench 上了一个大并发，但是只活了 300 多毫秒，这些连接都只活了 300 多毫秒，反复运行这个 sysbench 就可以将数据库打死，建立一千个连接，300 毫秒以后也会销毁，再建立一千个连接，你的业务就会忽上忽下，通过这个脚本就可以抓到这个压力从哪个服务器来的，哪个端口来的，然后把它搞定就可以了。

长连接分析：

除了短连接分析，还有长连接分析，哪一个业务端老在搞我的数据，老在往里写，总在往里读，搞的网络特别慢。

可以帮大家提供这样一个视角，它有读有写。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!