[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)

1. mysql> explain select web_page_object.web_page_object_id,  
2.     ->     web_page_object.object_id,  
3.     ->     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  
4.     ->     from web_page_div,web_page_object,object_media as om1,object_media as om2  
5.     ->     where web_page_div.id=web_page_object.web_page_div_id  
6.     ->     and web_page_object.object_media_id=om1.object_media_id  
7.     ->     and web_page_div.web_page_id=1200  
8.     ->     and if(web_page_object.object_media_id1=0,  
9.     ->             web_page_object.object_media_id=om2.object_media_id,  
10.     ->             web_page_object.object_media_id1=om2.object_media_id)  
11.     ->      
12.     ->     and '2014-05-01 15:09:49'>=start_time  
13.     ->     and '2014-05-01 15:09:49'<= end_time  
14.     ->     
15.     ->     and object_status=0  
16.     ->     order by web_page_div.id,web_page_object.position_sort;  
17. +----+-------------+-----------------+--------+-----------------------+---------+---------+-------------------------------------------+-------+----------------------------------------------------+  
18. | id | select_type | table           | type   | possible_keys         | key     | key_len | ref                                       | rows  | Extra                                              |  
19. +----+-------------+-----------------+--------+-----------------------+---------+---------+-------------------------------------------+-------+----------------------------------------------------+  
20. |  1 | SIMPLE      | web_page_object | ALL    | object_media_id_index | NULL    | NULL    | NULL                                      | 51165 | Using where; Using temporary; Using filesort       |  
21. |  1 | SIMPLE      | web_page_div    | eq_ref | PRIMARY,idx           | PRIMARY | 4       | db_jiapin.web_page_object.web_page_div_id |     1 | Using where                                        |  
22. |  1 | SIMPLE      | om1             | eq_ref | PRIMARY               | PRIMARY | 4       | db_jiapin.web_page_object.object_media_id |     1 | Using where                                        |  
23. |  1 | SIMPLE      | om2             | ALL    | NULL                  | NULL    | NULL    | NULL                                      | 74759 | Using where; Using join buffer (Block Nested Loop) |  
24. +----+-------------+-----------------+--------+-----------------------+---------+---------+-------------------------------------------+-------+----------------------------------------------------+  
25. Using join buffer (Block Nested Loop)  

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

还记录以前碰到的

1. (Block Nested Loop)的案例是 join后面的on条件里面有or判断。  

1. 也会引起Block Nested Loop，导致数据库负载过高。