mysql事件教程(关于MySQL报警的一次分析处理详解)
mysql事件教程
关于MySQL报警的一次分析处理详解最近有一个服务出现了报警,已经让我到了忍无可忍的地步,报警信息如下:
Metric:mysql.innodb_row_lock_waits Tags:port=4306,service=xxxx diff(#1): 996>900
大概的意思是有一个数据库监控指标 innodb_row_lock_waits 目前超出了阈值900
但是尴尬的是,每次报警后去环境中查看,得到的信息都很有限,慢日志,错误日志里面都没有充分的信息可以分析,一来二去之后,我开始静下心来分析这个问题的原因。
首先这个报警信息的时间点貌似是有些规律的,我拿着最近几天的报警时间做了比对,发现还是比较有规律的,那么在系统层面有哪些任务可能会触发呢,我查找比对了相关的任务配置,发现有一个定时任务每1分钟会执行一次,但是到了这里疑问就来了,如果每1分钟执行1次,为什么在特定的时间会产生差异较大的处理结果?当然这个现象的解释是个起始。
其实要证明这一点还是蛮容易的,今天我就采取了守株待兔的模式,我在临近报警的时间前后打开了通用日志,从日志输出来看,操作的频率还是相对有限的。
很快得到了规律性的报警,于是我开始抓取相关的通用日志记录,比如11:18分,我们可以采用如下的模式得到相关的日志,首先得到一个临时的通用日志文件,把各种DML和执行操作都网罗进来。
cat general.log|grep -E "insert|delete|update|select|exec" > general_tmp.log
我们以11:18分为例,可以在前后1两分钟做比对,结果如下:
# less general_tmp.log |grep "11:18"|wc -l
400
# less general_tmp.log |grep "11:17"|wc -l
666
# less general_tmp.log |grep "11:16"|wc -l
15
发现在报警的那1分钟前后,数量是能够对得上的。
这个表的数据量有200多万,表结构如下:
|
CREATE TABLE `task_queue` ( `AccID` bigint (20) NOT NULL AUTO_INCREMENT COMMENT '自增ID' , `TaskStepID` bigint (20) DEFAULT NULL COMMENT '任务步骤ID task_step_conf' , `QOrder` int (11) DEFAULT NULL COMMENT '队列排序 task_step_confi.Step_ID' , `QState` tinyint(4) DEFAULT '1' COMMENT '队列状态 1:待执行 2:执行中 3:执行成功 4:执行失败' , `QExcCount` int (11) DEFAULT '1' COMMENT '执行次数' , `CrtTime` datetime DEFAULT NULL COMMENT '创建时间' , `ModTime` datetime DEFAULT NULL COMMENT '修改时间' , PRIMARY KEY (`AccID`), KEY `idx_taskstepid` (`TaskStepID`), KEY `idx_qstate` (`QState`) ) ENGINE=InnoDB AUTO_INCREMENT=3398341 DEFAULT CHARSET=utf8 |
在日志中根据分析和比对,基本能够锁定SQL是在一类Update操作上面,SQL的执行计划如下:
|
>>explain update task_queue set QState=1,QExcCount=QExcCount+1,modtime=now() where QState=0 and taskstepid =411\G *************************** 1. row *************************** id : 1 select_type: UPDATE table: task_queue partitions: NULL type : index_merge possible_keys: idx_taskstepid,idx_qstate key: idx_qstate,idx_taskstepid key_len: 2,9 ref: NULL rows: 11 filtered: 100.00 Extra: Using intersect(idx_qstate,idx_taskstepid); Using where; Using temporary |
这个执行结果中key_len是2,9,是和以往的ken_len计算法则不一样的。 其中Extra列已经给出了明确的提示,这是一个intersect处理,特别的是它是基于二级索引级别的处理,在优化器层面是有一个相关的参数index_merge_intersection。
我们知道在MySQL中主键是一等公民,而二级索引最后都会映射到主键层面处理,而索引级别的intersect其实有点我们的左右手,左手对应一些数据结果映射到一批主键id,右手对应一些数据结果映射到另外一批主键id,把两者的主键id值进行intersect交集计算,所以在当前的场景中,索引级别的intersect到底好不好呢?
在此我设想了3个对比场景进行分析,首先这是一个update语句,我们为了保证后续测试的可重复性,可以转换为一个select语句。
|
select * from task_queue where QState=0 and taskstepid =411; |
所以我们的对比测试基于查询语句进行比对分析。
场景1:优化器保持默认index_merge_intersection开启,基于profile提取执行明细信息
|
>explain select * from task_queue where QState=0 and taskstepid =411\G *************************** 1. row *************************** id : 1 select_type: SIMPLE table: task_queue partitions: NULL type : index_merge possible_keys: idx_qstate,idx_taskstepid key: idx_qstate,idx_taskstepid key_len: 2,9 ref: NULL rows: 11 filtered: 100.00 Extra: Using intersect(idx_qstate,idx_taskstepid); Using where 1 row in set , 1 warning (0.00 sec) |
profile信息为:
场景2:优化器关闭index_merge_intersection,基于profile进行对比
|
> set session optimizer_switch= 'index_merge_intersection=off' ; >explain select * from task_queue where QState=0 and taskstepid =411\G *************************** 1. row *************************** id : 1 select_type: SIMPLE table: task_queue partitions: NULL type : ref possible_keys: idx_qstate,idx_taskstepid key: idx_qstate key_len: 2 ref: const rows: 1451 filtered: 0.82 Extra: Using where 1 row in set , 1 warning (0.00 sec) |
profile信息为:
场景3:重构索引,进行比对分析
根据业务逻辑,如果创建一个复合索引,是能够大大减少结果集的量级的,同时依然保留 idx_ qsta te 索引,使得一些业务依然能够正常使用。
|
>alter table task_queue drop key idx_taskstepid; >alter table task_queue add key `idx_taskstepid` (`TaskStepID`,QState); explain select * from task_queue where QState=0 and taskstepid =411\G *************************** 1. row *************************** id : 1 select_type: SIMPLE table: task_queue partitions: NULL type : ref possible_keys: idx_qstate,idx_taskstepid key: idx_taskstepid key_len: 11 ref: const,const rows: 1 filtered: 100.00 Extra: NULL 1 row in set , 1 warning (0.00 sec) |
profile信息为:
可以明显看到通过索引重构,“Sending data”的部分少了两个数量级
所以接下里的事情就是进一步进行分析和验证,有理有据,等待的过程也不再彷徨,一天过去了,再没有收到1条报警,再次说明在工作中不要小看这些报警。
总结
到此这篇关于关于MySQL报警分析处理的文章就介绍到这了,更多相关MySQL报警处理内容请搜索开心学习网以前的文章或继续浏览下面的相关文章希望大家以后多多支持开心学习网!
原文链接:https://www.tuicool.com/articles/FrAzi27
- mysql存储过程遍历数据(Mysql 存储过程中使用游标循环读取临时表)
- mysql流式查询(MySQL全面瓦解之查询的正则匹配详解)
- mysql数据表的创建与管理(MySQL数据操作-DML语句的使用)
- mysql innodb存储原理(mysql innodb的重要组件汇总)
- navicat连接mysql是远程连接吗(详解Navicat远程连接mysql很慢)
- mysql冷热数据分离方案(MySQL中使用流式查询避免数据OOM)
- mysql随机获取数据
- myeclipse连接mysql数据库的方法(教你用eclipse连接mysql数据库)
- centos7离线安装mysql5.7(CentOS7.5 安装MySql的教程)
- mysql用户登录命令(mysql的登陆和退出命令格式)
- MYSQL中GROUP BY不包含所有的非聚合字段时的注意事项
- mysql 高级用法(MySQL实现replace函数的几种实用场景)
- mysql8.0.23.0官方安装手册(MySQL8.0.23安装超详细教程)
- thinkphp5怎么设置默认返回(thinkphp5.1框架实现格式化mysql时间戳为日期的方式小结)
- 如何找到mysqlroot密码(WDCP管理面板忘记MYSQL ROOT密码及重置后台登录密码的方法汇总)
- mysql长连接释放和不释放的问题(解决MySQL存储时间出现不一致的问题)
- 苹果自研芯片跑分对比 A16芯片排名靠后,M1系列霸榜(苹果自研芯片跑分对比)
- X86处理器的梦魇 苹果M1自研芯片到底有多强(苹果M1自研芯片到底有多强)
- 泰剧《爱欲之神》Boom kitkong和Great合体杂志(泰剧爱欲之神Boomkitkong和Great合体杂志)
- 素人恋爱综艺火药味十足 男生为赢得芳心集体扯头花,真是出好戏(素人恋爱综艺火药味十足)
- 《囧妈》为何受抵制 春节七部影片撤档背后的责任与博弈(囧妈为何受抵制)
- 提醒 2019年起河南驾考要开设科目五 官方回应来了(2019年起河南驾考要开设科目五)
热门推荐
- 私有云需要企业自己买服务器吗(企业如何对私有云主机进行管理?)
- 属于web服务器的有哪些(web服务器有几种类型?)
- dede内容模型管理(Dede网站修改模板路径的方法 拒绝模板泄漏被盗)
- mysql变量技巧(mysql用户变量与set语句示例详解)
- laravel数据库操作方式(Laravel 实现数据软删除功能)
- python批量自动化访问网站(python 自动批量打开网页的示例)
- ideadocker调试(Idea部署远程Docker并配置文件)
- docker 容器运行的数据在哪里(docker容器的几种存储详解)
- 树莓派3B+安装64位ubuntu系统和docker工具的操作步骤详解(树莓派3B+安装64位ubuntu系统和docker工具的操作步骤详解)
- sqlserver2012tcpip配置(Sql Server2012 使用IP地址登录服务器的配置图文教程)
排行榜
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9