在此我设想了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报警处理内容请搜索
更多相关Mysql内容来自木庄网络博客
标签:Mysql
相关阅读 >>
更多相关阅读请进入《mysql》频道 >>

数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。