解释mysql慢查询(MySQL Threads_running飙升与慢查询的相关问题解决)
解释mysql慢查询
MySQL Threads_running飙升与慢查询的相关问题解决背景
年前本应该是回顾一年工作和收尾的阶段,奈何各种促销,活动都等着春节,因此也遇到了不少的问题,回顾了一下最近遇到的问题,发现有好几个问题比较类似,正好整理一下,作为年前收尾的案例吧。表现上都是数据库假死,无响应,发生的场景有较高的业务压力到来时,也有业务正常运行的时候,突然就出现问题了。
问题描述
由于腾讯云数据库 MySQL 本身是有故障检测和高可用机制的,这几例问题发生的时候,从用户反馈的问题出现的时间点到实际介入排查的时候已经有好几分钟了,但是并没有触发高可用切换,说明这个问题可能并不是数据库自身的故障,也不是一些外部原因导致数据库不可用。
检查一下数据库当时候的状态,发现一个很不正常的指标:
在问题的时间点附近,连接数的总数量和 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,查询的效率比较低,所以根因还是慢查询。
拓展一下
如开篇所提及,最近发生的问题有多起,且原因类似。除了这个飙升的案例,还有如下所示的现象。
threads_running 保持在一个相对平稳的数值,参考前文的分析,可以发现这个现象代表着在平时的时候,就有约 10 个查询长时间处于活跃状态,可以预测一个故障场景:业务量继续上升,活跃的查询变多,当高效的查询受影响,效率降低到一定程度的时候,前端程序/用户会因为超时或者响应慢的原因,发起重试,然后因为查询效率降低,这个重试被反复触发,然后引发雪崩效应,慢慢拖垮数据库。
万幸的是多个类似现象的实例仅有一个出现了问题,就是预测的这个场景,其他的都及时优化掉了。
总结一下
虽说仍旧是慢查询的问题,但是从这个案例可以发现另外一个 MySQL 指标,threads_running 的用处:监控活跃的连接,提前发现一些并发量过高和异常的查询,防止数据库堆积查询,产生假死的现象。
以上就是MySQL Threads_running飙升与慢查询的问题解决的详细内容,更多关于MySQL Threads_running飙升与慢查询的资料请关注开心学习网其它相关文章!
- 常见的mysql优化策略(MySQL pt-slave-restart工具的使用简介)
- 如何查找MySQL中查询慢的SQL语句
- mysql各种备份方式(MySQL 逻辑备份与恢复测试的相关总结)
- docker 增大mysql连接数(docker中修改mysql最大连接数及配置文件的实现)
- mysql清空数据库所有表格(MySQL用truncate命令快速清空一个数据库中的所有表)
- mysql8.0配置优化参数(MySQL 8.0 新特性之检查约束的实现)
- mysql mvcc 流程(Mysql MVCC机制原理详解)
- navicat不能连接到mysql报错2013(Navicat连接SQL Server数据:报错08001-命名管道提供程序的完美解决方法)
- mysql索引优化有哪些(MySQL如何基于Explain关键字优化索引功能)
- mysql出现的问题及解决方法(mysql升级到5.7时,wordpress导数据报错1067的问题)
- mysql常见错误分析(分析MySQL抛出异常的几种常见解决方式)
- mysql数据库简单操作(一篇文章教会你进行MySQL数据库和数据表的基本操作)
- 怎样查看mysql的安装路径(MySQL中查看数据库安装路径的方法)
- 如何查看mysql执行计划(到底什么是Mysql执行计划?)
- mysql8.0.15安装详细教程(mysql8.0.11数据目录迁移的实现)
- mysql 查询json(MySQL处理JSON常见函数的使用)
- 刘韬涛丁子贺小品《根治低头族》台词剧本(刘韬涛丁子贺小品根治低头族台词剧本)
- 看完《夺冠》,黄渤的演技我实在夸不起来,彭昱畅反令人惊喜(黄渤的演技我实在夸不起来)
- 黄渤泪目 我的痴呆父亲,我内心永远的痛(黄渤泪目我的痴呆父亲)
- 蒜苔和鱿鱼尾巴一起炒,味道特别棒,又脆又嫩,有滋又有味(蒜苔和鱿鱼尾巴一起炒)
- 鱿鱼炒蒜苔不是黑暗料理,这样做清香扑鼻,鲜美脆嫩,开胃又下饭(鱿鱼炒蒜苔不是黑暗料理)
- 蒜苔炒鱿鱼(蒜苔炒鱿鱼)
热门推荐
- python获取游戏画面信息(python游戏开发之视频转彩色字符动画)
- react和antd项目教程(React引入antd-mobile+postcss搭建移动端)
- mysql数据类型及用法(MySQL数据库重命名的快速且安全方法3种)
- dedecms标签怎么调用(织梦DEDECMS获取当前页面的顶级栏目名称及链接教程)
- dedecms怎么加页面(dedecms导航判断当前选中样式的方法)
- SQL Server中查询CPU占用高的SQL语句
- VS中打开.ashx文件
- html网页设计排版布局(HTML利用九宫格原理进行网页布局)
- 国产云主机哪个好(便宜好用的国内云主机怎么挑选?)
- docker容器退出错误码的步骤(docker容器退出错误码的步骤)
排行榜
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9