[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

推薦度：

點擊下載本文 文檔為doc格式

導讀[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再跑?？床l，當前的線程總數量也才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的解決過程

推薦度：

點擊下載本文 文檔為doc格式

標簽： cpu 12 線上

熱門焦點

[MySQLCPU]線上爬升800%，load達到12的解決過程

[MySQLCPU]線上爬升800%，load達到12的解決過程

[MySQLCPU]線上爬升800%，load達到12的解決過程

最新推薦

猜你喜歡

熱門推薦

[MySQLCPU]線上爬升800%，load達到12的解決過程

[MySQLCPU]線上爬升800%，load達到12的解決過程

[MySQLCPU]線上爬升800%，load達到12的解決過程

最新推薦

猜你喜歡

熱門推薦

[MySQLCPU]線上爬升800%，load達到12的解決過程

[MySQLCPU]線上爬升800%，load達到12的解決過程