您当前的位置:首页 > 电脑百科 > 数据库 > MYSQL

一条MySQL报警的分析思路

时间:2020-02-03 09:22:50  来源:  作者:

今天带着同事一起分析了一个常见的MySQL慢日志报警,从分析的过程希望带给大家一些启示和反思。

报警信息类似:

PROBLEM P5 Endpoint:xxxx Metric:mysql.slow_queries Tags:idc=IDC1,port=4306,service=test diff(#1): 335>300 Note:[[warning]SQL语句执行效率慢] Max:3, .....

看到这条报警信息,可以明确一个任务,此时数据库中存在大量的慢日志,条数为335,超出了阈值设置的300

当然打开日志来分析的时候,会发现比想象的要复杂一些,因为慢日志文件可能有几百兆甚至更大,要分析整个文件显然是不可行的,所以我们需要过滤条件,把慢日志限定在一个较小的范围内来分析。

这里我们可以使用mysqldumpslow来做一个简单的分析,推荐更好的一款工具是pt-query-digest。

如下是慢日志的头部:

一条MySQL报警的分析思路

 

可以明显看到在1分钟的时间里SQL执行的整体情况,1分钟内有400多的SQL执行。但是仔细看指标“Exec time”会有一个明显的问题,那就是这个时长指标其实很低,总数才881ms,显然是不符合我们理解中的慢日志阈值的。

所以我们可以得到一个基本的印象,这个指标是和一个慢日志相关的参数:log_queries_not_using_indexes 相关,这个参数意思是如果SQL没有使用索引则会计入慢日志。

为了做进一步验证,我们往下看profile.

一条MySQL报警的分析思路

 

看profile信息的时候我们要按照重点来把握,即那些明显的性能SQL占比通常很高。如果检查前两个表会发现,根据现在的条件,这两条SQL的where条件部分是没有相关的索引的。

第一个SQL有点意思。

UPDATE SELECT dic_push_dao_assistant tem_selectAssDAO。。。

这是什么意思,我们可以详细的Query ID的解析来得到。对于update语句会转义成等价的select语句

update `dic_push_dao_assistant`
 set `state` = 1
 where `id` in 
 (
select `id`
 from `tem_selectAssDAO`
 )G
# Converted for EXPLAIN
# EXPLAIN /*!50100 PARTITIONS*/
select `state` = 1 from `dic_push_dao_assistant` where `id` in 
 (
select `id`
 from `tem_selectAssDAO`
 )G

当然这个语句本身是有些粗糙,完全可以进一步优化。

我们再分析一下第2条SQL,问题是很明显的,即相关的SQL缺少索引而走了全表扫描。

但是建议还是做下补充,可能这些信息是在慢日志之外,就是建表语句:

一条MySQL报警的分析思路

 

从这里我们可以清晰的看出,这个表只有2190条记录,目前的扫描基本就是少数几个页就搞定了,但是自增列已经到了1000万左右,可以看出这个表的变更是极为频繁的,那么是否存在碎片呢。验证的方式我们可以直接查看对应的物理文件,可以看到2000条记录大概占用了20M左右的空间,这能不能说明有碎片呢。

# ll *cccd*

-rw-r----- 1 mysql mysql 70494 Nov 20 09:37 dic_fsm_cccd_info.frm

-rw-r----- 1 mysql mysql 26214400 Feb 27 17:50 dic_fsm_cccd_info.ibd

验证方式其实也不难,我们在另外一个库中模拟创建一个表补充数据即可,大概是10M左右。

# ll *cccd*

-rw-r----- 1 mysql mysql 70494 Feb 27 23:47 dic_fsm_cccd_info.frm

-rw-r----- 1 mysql mysql 10485760 Feb 27 23:48 dic_fsm_cccd_info.ibd

所以目前来看这个表是存在碎片的,说明大量的数据是写入了库中,然后很可能做了delete操作,导致数据总量变化不大,按照这种方式是存在隐患的。

从自增列来看,很可能数据会出现较大的增长,就会导致这个操作马上成为瓶颈,这条SQL一分钟执行了144次,算是比较频繁了,所以从目前的情况来看,这个表很可能成为性能的瓶颈,所以需要建议业务评估添加相关的索引。而之前根据业务的反馈,说这个库经常会有一些操作的延迟,也不难理解了。

我们在这里处理应该得出什么结论呢?

1)关闭参数log_queries_not_using_indexes

2)对相关的表进行分析,根据条件和频率创建相应的索引

其实到了这里,我们的分析还是不够深入,我们可以发掘出更多的信息,那就是可以提供给业务方一个更全面的信息列表,比如那些表中的索引是冗余索引,那些表走了全表扫描需要考虑添加索引。

这里需要正确引用sys schema,比如:

一条MySQL报警的分析思路

 

通过如上的信息可以发现我们需要重点考虑前面的几个表,走了全表扫描,产生了较大的延迟。

而稍后的解决方法,其实是通过对于业务的反馈优化,在业务添加了相关索引之后,还是建议打开参数:log_queries_not_using_indexes ,这对于一些业务场景的监控其实也是有效的。

如此一来,我们对慢日志的分析也告一段落,如果对于每条报警信息我们都认真对待,其实相应技术能力的提升也会很快。

其实行业里有一个常见的“伪需求“,就是开发同学经常需要关注慢日志,从工作的角色和分工来看,他们得到慢日志之后的分析和处理常常和问题的本质相左,换句话说,他们得到慢日志,是希望通过分析日志来发现一些明显的性能问题,通过这种信息检索的方式,来快速定位问题,但是实际上得到日志之后的分析结果是不可控的,可能10分钟,可能分析不出来。

而这个工作其实是应该作为运维的前置工作来完成的,既然开发对于慢日志的处理不专业,势必需要DBA来提供专业的建议,而如果我们能够通过一种透明自助的方式来提供分析和有效建议,对于开发同学来说,其实他们需要的不是慢日志,而是你的数据服务能力。



Tags:MySQL报警   点击:()  评论:()
声明:本站部分内容来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除,谢谢。
▌相关评论
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
▌相关推荐
今天带着同事一起分析了一个常见的MySQL慢日志报警,从分析的过程希望带给大家一些启示和反思。报警信息类似:PROBLEM P5 Endpoint:xxxx Metric:mysql.slow_queries Tags:idc=I...【详细内容】
2020-02-03   MySQL报警  点击:(3)  评论:(0)  加入收藏
相关文章
    无相关信息
最新更新
栏目热门
栏目头条