mysql占用CPU過高的解決辦法(添加索引)
更新時間:2013年03月19日 16:15:56 作者:
下面是MYSQL占用CPU高處理的一個例子,希望對遇到類似問題的朋友們有點啟發(fā)。一般來說MYQL占用CPU高,多半是數據庫查詢代碼問題,查詢數據庫過多。所以一方面要精簡代碼,另一方面最好對頻繁使用的代碼設置索引
下面是MYSQL占用CPU高處理的一個例子,希望對遇到類似問題的朋友們有點啟發(fā)。一般來說MYQL占用CPU高,多半是數據庫查詢代碼問題,查詢數據庫過多。所以一方面要精簡代碼,另一方面最好對頻繁使用的代碼設置索引。
今天早上起來 機器報警 一查負載一直都在4以上
top了一下 發(fā)現 mysql 穩(wěn)居 第一 而且相當穩(wěn)定 我擦
重啟一下mysql不行
mysql> show processlist;一下
發(fā)現xxx網站有兩條 查詢語句 一直 在列,我擦 該站 也就30多萬條記錄 量也不大 不可能是機器性能問題
忽然 記得以前在網上看過說是 tmp_table_size值太小會造成這種情況;
于是mysql -pxxx -e "show variables;" >tmp
一看是默認的32M(顯示出來的是字節(jié)數)
于是翁就開心的改了起來 增加到256 重啟 mysql 。。結果很失望
不行啊 還得再來
select 一下該表 發(fā)現 里面 都是論壇留言的東西 量還挺大
于是:
mysql> show columns from bbs_message;
+-----------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+----------------+
| msg_id | int(11) | NO | PRI | NULL | auto_increment |
| board_id | int(11) | NO | MUL | 0 | |
| parent_id | int(11) | NO | MUL | 0 | |
| root_id | int(11) | NO | MUL | 0 | |
一直在show processlist 里面出現的 就是 select * from bbs_message where board_id=xxx and parent_id=xxx
和 select * from bbs_message where parent_id=xxx
只要這兩條一出現 cpu就上去了
于是 從索引入手:
增加兩條索引
mysql> alter table bbs_message add index parentid(parent_id);
alter table bbs_message add index chaxunid(board_id,parent_id);
最后查看一下索引結果:
mysql> show index from bbs_message;
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| bbs_message | 0 | PRIMARY | 1 | msg_id | A | 2037 | NULL | NULL | | BTREE | |
| bbs_message | 1 | rootid | 1 | root_id | A | 49 | NULL | NULL | | BTREE | |
| bbs_message | 1 | chaxunid | 1 | board_id | A | 3 | NULL | NULL | | BTREE | |
| bbs_message | 1 | chaxunid | 2 | parent_id | A | 135 | NULL | NULL | | BTREE | |
| bbs_message | 1 | parentid | 1 | parent_id | A | 127 | NULL | NULL | | BTREE | |
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
5 rows in set (0.00 sec)
退出 在 top 一下 負載一直在0.x 很穩(wěn)定
今天早上起來 機器報警 一查負載一直都在4以上
top了一下 發(fā)現 mysql 穩(wěn)居 第一 而且相當穩(wěn)定 我擦
重啟一下mysql不行
mysql> show processlist;一下
發(fā)現xxx網站有兩條 查詢語句 一直 在列,我擦 該站 也就30多萬條記錄 量也不大 不可能是機器性能問題
忽然 記得以前在網上看過說是 tmp_table_size值太小會造成這種情況;
于是mysql -pxxx -e "show variables;" >tmp
一看是默認的32M(顯示出來的是字節(jié)數)
于是翁就開心的改了起來 增加到256 重啟 mysql 。。結果很失望
不行啊 還得再來
select 一下該表 發(fā)現 里面 都是論壇留言的東西 量還挺大
于是:
mysql> show columns from bbs_message;
+-----------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+----------------+
| msg_id | int(11) | NO | PRI | NULL | auto_increment |
| board_id | int(11) | NO | MUL | 0 | |
| parent_id | int(11) | NO | MUL | 0 | |
| root_id | int(11) | NO | MUL | 0 | |
一直在show processlist 里面出現的 就是 select * from bbs_message where board_id=xxx and parent_id=xxx
和 select * from bbs_message where parent_id=xxx
只要這兩條一出現 cpu就上去了
于是 從索引入手:
增加兩條索引
mysql> alter table bbs_message add index parentid(parent_id);
alter table bbs_message add index chaxunid(board_id,parent_id);
最后查看一下索引結果:
mysql> show index from bbs_message;
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| bbs_message | 0 | PRIMARY | 1 | msg_id | A | 2037 | NULL | NULL | | BTREE | |
| bbs_message | 1 | rootid | 1 | root_id | A | 49 | NULL | NULL | | BTREE | |
| bbs_message | 1 | chaxunid | 1 | board_id | A | 3 | NULL | NULL | | BTREE | |
| bbs_message | 1 | chaxunid | 2 | parent_id | A | 135 | NULL | NULL | | BTREE | |
| bbs_message | 1 | parentid | 1 | parent_id | A | 127 | NULL | NULL | | BTREE | |
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
5 rows in set (0.00 sec)
退出 在 top 一下 負載一直在0.x 很穩(wěn)定
相關文章
mysql8.0?lower_case_table_names?大小寫敏感設置問題解決
在默認情況下,這個變量是設置為0的,以保持向前兼容性,如果將該變量設置為1,則表名和數據庫名將被區(qū)分大小寫,本文主要介紹了mysql8.0?lower_case_table_names?大小寫敏感設置問題解決,感興趣的可以了解一下2023-09-09Mysql匿名登錄無法創(chuàng)建數據庫問題解決方案
這篇文章主要介紹了Mysql匿名登錄無法創(chuàng)建數據庫問題解決方案,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-12-12Window 下安裝Mysql5.7.17 及設置編碼為utf8的方法
這篇文章主要介紹了Window 下安裝Mysql5.7.17 及設置編碼為utf8的方法,非常不錯,具有參考借鑒價值,需要的朋友可以參考下2017-03-03MySQL約束之默認約束default與零填充約束zerofill
這篇文章主要介紹了MySQL約束之默認約束default與零填充約束zerofill,MySQL?默認值約束用來指定某列的默認值。更多相關資料需要的朋友可以參考一下2022-07-07