最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
问答文章1 问答文章501 问答文章1001 问答文章1501 问答文章2001 问答文章2501 问答文章3001 问答文章3501 问答文章4001 问答文章4501 问答文章5001 问答文章5501 问答文章6001 问答文章6501 问答文章7001 问答文章7501 问答文章8001 问答文章8501 问答文章9001 问答文章9501
当前位置: 首页 - 科技 - 知识百科 - 正文

[MySQLCPU]线上爬升800%,load达到12的解决过程

来源:懂视网 责编:小采 时间:2020-11-09 13:33:59
文档

[MySQLCPU]线上爬升800%,load达到12的解决过程

[MySQLCPU]线上爬升800%,load达到12的解决过程:[MySQL CPU]线上飙升800%,load达到12的解决过程 接到报警通知,负载过高,达到800%,load也过高,有11了。 MySQL版本为5.6.12-log 1 top 之后,确实是mysqld进程占据了所有资源。 2 查看error日志,无任何异常 3 show eninge innod
推荐度:
导读[MySQLCPU]线上爬升800%,load达到12的解决过程:[MySQL CPU]线上飙升800%,load达到12的解决过程 接到报警通知,负载过高,达到800%,load也过高,有11了。 MySQL版本为5.6.12-log 1 top 之后,确实是mysqld进程占据了所有资源。 2 查看error日志,无任何异常 3 show eninge innod

[MySQL CPU]线上飙升800%,load达到12的解决过程 接到报警通知,负载过高,达到800%,load也过高,有11了。 MySQL版本为5.6.12-log 1 top 之后,确实是mysqld进程占据了所有资源。 2 查看error日志,无任何异常 3 show eninge innodb status\G,没有死锁信息

[MySQL CPU]线上飙升800%,load达到12的解决过程

接到报警通知,负载过高,达到800%,load也过高,有11了。

MySQL版本为5.6.12-log


1 top 之后,确实是mysqld进程占据了所有资源。


2 查看error日志,无任何异常


3 show eninge innodb status\G,没有死锁信息。


4 show full processlist;

没有耗时非常大的慢sql再跑。看并发,当前的线程总数量也才30个左右。


5 查看iostat,读写正常。


到底是什么问题呢?查看slow log,发现如下SQL,频繁执行,耗时在5秒之间,explain有Using join buffer (Block Nested Loop)

mysql> explain select web_page_object.web_page_object_id,
 -> web_page_object.object_id,
 -> web_div_name,web_page_object.position_sort,web_page_object.end_time,om1.label,om1.file,jump_url,om2.label as label1,om2.file as file1
 -> from web_page_div,web_page_object,object_media as om1,object_media as om2
 -> where web_page_div.id=web_page_object.web_page_div_id
 -> and web_page_object.object_media_id=om1.object_media_id
 -> and web_page_div.web_page_id=1200
 -> and if(web_page_object.object_media_id1=0,
 -> web_page_object.object_media_id=om2.object_media_id,
 -> web_page_object.object_media_id1=om2.object_media_id)
 -> 
 -> and '2014-05-01 15:09:49'>=start_time
 -> and '2014-05-01 15:09:49'<= end_time
 -> 
 -> and object_status=0
 -> order by web_page_div.id,web_page_object.position_sort;
+----+-------------+-----------------+--------+-----------------------+---------+---------+-------------------------------------------+-------+----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------------+--------+-----------------------+---------+---------+-------------------------------------------+-------+----------------------------------------------------+
| 1 | SIMPLE | web_page_object | ALL | object_media_id_index | NULL | NULL | NULL | 51165 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | web_page_div | eq_ref | PRIMARY,idx | PRIMARY | 4 | db_jiapin.web_page_object.web_page_div_id | 1 | Using where |
| 1 | SIMPLE | om1 | eq_ref | PRIMARY | PRIMARY | 4 | db_jiapin.web_page_object.object_media_id | 1 | Using where |
| 1 | SIMPLE | om2 | ALL | NULL | NULL | NULL | NULL | 74759 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-----------------+--------+-----------------------+---------+---------+-------------------------------------------+-------+----------------------------------------------------+
Using join buffer (Block Nested Loop)


看SQL是where后面的if判断引起的,拆分if之后,就正常了,SQL耗时不到0.1秒。数据库load也降下来了。


还记录以前碰到的

(Block Nested Loop)的案例是 join后面的on条件里面有or判断。
也会引起Block Nested Loop,导致数据库负载过高。

声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文档

[MySQLCPU]线上爬升800%,load达到12的解决过程

[MySQLCPU]线上爬升800%,load达到12的解决过程:[MySQL CPU]线上飙升800%,load达到12的解决过程 接到报警通知,负载过高,达到800%,load也过高,有11了。 MySQL版本为5.6.12-log 1 top 之后,确实是mysqld进程占据了所有资源。 2 查看error日志,无任何异常 3 show eninge innod
推荐度:
标签: cpu 12 线上
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top