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 实例中。而且从这个案例的监控图表来看，是一个飙升的趋势，说明是在短时间内出现了大量的活跃连接。

分析

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

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

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

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

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

拓展一下

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

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

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

总结一下

虽说仍旧是慢查询的问题，但是从这个案例可以发现另外一个 MySQL 指标，threads_running 的用处：监控活跃的连接，提前发现一些并发量过高和异常的查询，防止数据库堆积查询，产生假死的现象。

以上就是MySQL Threads_running飙升与慢查询的问题解决的详细内容，更多关于MySQL Threads_running飙升与慢查询的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • 通过MySQL慢查询优化MySQL性能的方法讲解

    通过MySQL慢查询优化MySQL性能的方法讲解

    随着访问量的上升,MySQL数据库的压力就越大,几乎大部分使用MySQL架构的web应用在数据库上都会出现性能问题,通过mysql慢查询日志跟踪有问题的查询非常有用,可以分析出当前程序里有很耗费资源的sql语句. 慢查询日志我们可以通过my.cnf文件设置开启,下面先来看一下相关参数的意义 log-slow-queries <slow_query_log_file> 存放slow query日志的文件.你必须保证mysql server进程mysqld_safe进程用户对该文件有w权限. lo

  • MYSQL慢查询和日志实例讲解

    一.简介 开启慢查询日志,可以让MySQL记录下查询超过指定时间的语句,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能. 二.参数说明 slow_query_log 慢查询开启状态 slow_query_log_file 慢查询日志存放的位置(这个目录需要MySQL的运行帐号的可写权限,一般设置为MySQL的数据存放目录) long_query_time 查询超过多少秒才记录 三.设置步骤 1.查看慢查询相关参数 mysql> show variables like 'slow_quer

  • MySQL 慢查询日志的开启与配置

    简介 MySQL 慢查询日志是排查问题 SQL 语句,以及检查当前 MySQL 性能的一个重要功能. 查看是否开启慢查询功能: mysql> show variables like 'slow_query%'; +---------------------+------------------------------------+ | Variable_name | Value | +---------------------+----------------------------------

  • MySQL慢查询如何定位详解

    前言 相信大家在平时工作中都有过 SQL 优化经历,那么在优化前就必须找到慢 SQL 方可进行分析.这篇文章就介绍下如何定位到慢查询. 慢查询日志是 MySQL 内置的一项功能,可以记录执行超过指定时间的 SQL 语句. 以下是慢查询的相关参数,大家感兴趣的可以看下: 参数 含义 log_output 日志输出位置,默认为 FILE,即保存为文件,若设置为 TABLE,则将日志记录到 mysql.show_log 表中,支持设置多种格式 slow_query_log_file 指定慢查询日志文件

  • MySQL慢查询的坑

    MySQL慢查询的坑

    一条慢查询会造成什么后果?年轻时,我一直觉得不就是返回数据会慢一些么,用户体验变差?其实远远不止,我经历过几次线上事故,有一次就是由一条SQL慢查询导致的. 记得那是一条查询SQL,数据量万级时还保持在0.2秒内,随着某一段时间数据猛增,耗时一度达到了2-3秒!没有命中索引,导致全表扫描.explain 中extra显示:Using where; Using temporary; Using filesort,被迫使用了临时表排序,由于是高频查询,并发一起来很快就把DB线程池打满了,导致大量查询

  • Mysql sql慢查询监控脚本代码实例

    1.修改my.cnf #整体的效果,全局开启表和日志文件都写,但是对于general_log只写表,对于slow_query_log,表和日志文件都记录. general_log=1#开启mysql执行sql的日志 slow_query_log=1#开启mysql慢sql的日志 #设置之后会影响general_log和slow_query_log, log_output=table,File#日志输出会写表,也会写日志文件,为了便于程序去统计,所以最好写表 #这里没配置general_log_f

  • MySQL慢查询日志的作用和开启

    前言 MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中.long_query_time的默认值为10,意思是运行10S以上的语句.默认情况下,Mysql数据库并不启动慢查询日志,需要我们手动来设置这个参数,当然,如果不是调优需要的话,一般不建议启动该参数,因为开启慢查询日志会或多或少带来一定的性能影响.慢查询日志支持将日志记录写入文件,也支持将日志记录写入数据

  • Mysql慢查询优化方法及优化原则

    1.日期大小的比较,传到xml中的日期格式要符合'yyyy-MM-dd',这样才能走索引,如:'yyyy'改为'yyyy-MM-dd','yyyy-MM'改为'yyyy-MM-dd'[这样MYSQL会转换为日期类型] 2.条件语句中无论是等于.还是大于小于,WHERE左侧的条件查询字段不要使用函数或表达式或数学运算 3.WHERE条件语句尝试着调整字段的顺序提升查询速度,如把索引字段放在最前面.把查询命中率高的字段置前等 4.保证优化SQL前后其查询结果是一致的 5.在查询的时候通过将EXPLA

  • MySQL5.7慢查询日志时间与系统时间差8小时原因详解

    在对慢查询进行查看的时候发现时间不对,正好与系统时间相差8个小时. 1.慢查询显示时间如下 # Time: 2020-01-10T06:42:24.940811Z 2.系统时间 $ date Fri Jan 10 14:42:31 CST 2020 3.查看数据库参数 mysql> show variables like 'log_timestamps'; +----------------+-------+ | Variable_name | Value | +----------------

  • MySQL开启慢查询方法及实例

    一.简介 开启慢查询日志,可以让MySQL记录下查询超过指定时间的语句,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能. 二.参数说明 slow_query_log 慢查询开启状态 slow_query_log_file 慢查询日志存放的位置(这个目录需要MySQL的运行帐号的可写权限,一般设置为MySQL的数据存放目录) long_query_time 查询超过多少秒才记录 三.设置步骤 1.查看慢查询相关参数 mysql> show variables like 'slow_quer

  • MYSQL慢查询与日志的设置与测试

    一.简介 开启慢查询日志,可以让MySQL记录下查询超过指定时间的语句,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能. 二.参数说明 slow_query_log 慢查询开启状态 slow_query_log_file 慢查询日志存放的位置(这个目录需要MySQL的运行帐号的可写权限,一般设置为MySQL的数据存放目录) long_query_time 查询超过多少秒才记录 三.设置步骤 1.查看慢查询相关参数 mysql> show variables like 'slow_quer

  • 实例讲解MySQL 慢查询

    简介 开启慢查询日志,可以让MySQL记录下查询超过指定时间的语句,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能. 一.配置慢查询 1.参数说明 slow_query_log : 慢查询开启状态(默认关闭) slow_query_log_file : 慢查询日志存放的位置(这个目录需要MySQL的运行帐号的可写权限, 一般设置为MySQL的数据存放目录) long_query_time : 查询超过多少秒才记录(默认10秒) 2.查看慢查询相关参数 show variables lik

随机推荐