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

这段程序的逻辑是这样的：

• 在 query 开始的时候截获一下，让它记录一个时间戳；
• 请求结束的时候再截获一下记录一个时间戳；
• 把两个时间戳相减获得一个延迟；
• 把这个延迟扔到结果集里边去，程序就完成了。

我用结束时间减开始时间，减一下得到一个延迟，然后把延迟扔到一个统计容器里面，这个事就结束了。这是我要写的第一个程序，是嵌到内核里的程序，但是需要一个外壳的程序负责嵌入。

这个外壳程序的逻辑也非常简单，把刚才那段内核的程序嵌到 MySQL 的观测点上，嵌到内核里面去，然后把结果集拿出来，打印出来就结束了，这是如何写一个 eBPF 的脚本，大家唯一需要做的事情就是这两个程序，然后运行一下。

这个程序的核心只有 45 行，中间忽略了负责差错处理的一部分。只需要把现在的脚本拿下来抄一抄，改一改就可以完成很多的功能了。

这么好的方法为什么很多人不知道呢？

• 操作系统内核的限制，这个功能是 Linux 4.4 引进来的，但是在 Linux 4.4 上存在统计的 bug，我们推荐的是 Linux 4.9+，部分好用的功能是在 4.13+ 上才开放，这个是 eBPF 最大的限制。怎么办呢？只能祝大家长寿吧！活到 Linux 4.x 内核能在生产环境上使用的那一天。
• 它的第二个最大的限制是 MySQL 的编译参数，MySQL 虽然在很早的时候已经提供了 dtrace 的观测点，这些观测点是公用的，但是它在默认的编译出来的官方发布的包里边是不带观测点编译的，所以在直接官方发布的二进制的包里边是用不了这个功能的，大家需要自己编译一下。编译的时候需要带这个参数，这个可能也是属于一个比较大的限制。

所以如果大家受到限制，再推荐换一个工具：systemtap。

Linux 2.6 就已经有了，但是它的机制是写一个内核模块，这种机制其实不是特别稳定，它为了解决不是特别稳定的问题增加了若干限制，比如说能在内核中使用的内存大小有限制，采集频率也有限制，对整个内核性能的影响百分比也有限制，在这些限制参数都开起来的情况下，它还是比较安全的。

但是很多观测功能就必须要把这些限制关掉，一旦关掉内核就不是很稳定，所以这个工具，我没有敢把它的缺点写在上面因为确实是个好的工具，我们也很难说它的这个缺点是个致命的缺陷，但是不太推荐在生产环境上使用，但是在测试环境上确实是非常好玩的一个工具，如果大家用不了 eBPF 的话可以用 systemtap 来做一些诊断。

还有很多其他的工具：

至于如何选择，大家直接谷歌一下有专门的文章教大家怎么选择这些观测工具。但是总的来说没有一个科学的思路，只有尝试，不停的尝试。

黄炎，爱可生研发总监，深入钻研分布式数据库相关技术，擅长业界相关 MySQL 中间件产品和开发，以及分布式中间件在企业内部的应用实践。

【编辑推荐】

1. Innodb中MySQL如何快速删除2T的大表
2. 为什么你的MySQL性能差？死代码牵连问题解决了吗？
3. 连跳7个版本之后，MySQL 8.0.12有什么新特性？
4. MariaDB和MySQL全面对比：选择数据库需要考虑这几点
5. 带你深入了解MySQL的索引

（编辑：核心网）

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