詳細介紹Mysql占用過高CPU時的優化手段

Mysql占用CPU過高的時候，該從哪些方面下手進行優化？

占用CPU過高，可以做如下考慮：

1）一般來講，排除高并發的因素，還是要找到導致你CPU過高的哪幾條在執行的SQL，show processlist語句，查找負荷最重的SQL語句，優化該SQL，比如適當建立某字段的索引；

2）打開慢查詢日志，將那些執行時間過長且占用資源過多的SQL拿來進行explain分析，導致CPU過高，多數是GroupBy、OrderBy排序問題所導致，然后慢慢進行優化改進。比如優化insert語句、優化group by語句、優化order by語句、優化join語句等等；

3）考慮定時優化文件及索引；

4）定期分析表，使用optimize table；

5）優化數據庫對象；

6）考慮是否是鎖問題；

7）調整一些MySQL Server參數，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；

8）如果數據量過大，可以考慮使用MySQL集群或者搭建高可用環境。

9）可能由于內存latch（泄露）導致數據庫CPU高

10）在多用戶高并發的情況下，任何系統都會hold不住的，所以，使用緩存是必須的，使用memcached或者redis緩存都可以；

11）看看tmp_table_size大小是否偏小，如果允許，適當的增大一點；

12）如果max_heap_table_size配置的過小，增大一點；

13）mysql的sql語句睡眠連接超時時間設置問題（wait_timeout）

14）使用show processlist查看mysql連接數，看看是否超過了mysql設置的連接數

下面分享一例遇到過的案例：

網站在高峰時段訪問，點擊頁面有點卡。登陸服務器，發現機器負載有點高，并且mysql占用了很高的CPU資源，如下圖：

MySQL負載居高不下，如果打開了慢查詢日志功能，最好的辦法就是針對慢查詢日志里執行慢的sql語句進行優化，如果sql語句用了大量的group by等語句，union聯合查詢等肯定會將mysql的占用率提高。所以就需要優化sql語句

除了優化sql語句外，也可以做一些配置上的優化。在mysql中運行show proceslist;出現下面回顯結果：

1.查詢有大量的Copying to tmp table on disk狀態

明顯是由于臨時表過大導致mysql將臨時表寫入硬盤影響了整體性能。

Mysql中tmp_table_size的默認值僅為16MB，在當前的情況下顯然是不夠用的。

mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmp
dir
 | /tmp |
| tmp_table_size | 16777216 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in 
set
 (0.00 sec)

解決辦法：調整臨時表大小

1）進mysql終端命令修改，加上global,下次進mysql就會生效

mysql> set global tmp_table_size=33554432;
Query OK, 0 rows affected (0.00 sec)

再次登陸mysql

mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 33554432 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.01 sec)

2）my.cnf配置文件修改

[root@www ~]# vim my.cnf
.....
tmp_table_size = 32M

重啟mysql

[root@www ~]# /etc/init.d/mysqld restart

2.show processlist;命令的輸出結果顯示了有哪些線程在運行，可以幫助識別出有問題的查詢語句。比如下面結果：

Id User Host db Command Time State Info 
207 root 192.168.1.25:51718 mytest Sleep 5 
NULL

先簡單說一下各列的含義和用途，第一列，id，不用說了吧，一個標識，你要kill一個語句的時候很有用。user列，顯示單前用戶，如果不是root，這個命令就只顯示你權限范圍內的sql語句。host列，顯示這個語句是從哪個ip的哪個端口上發出的。呵呵，可以用來追蹤出問題語句的用戶。db列，顯示這個進程目前連接的是哪個數據庫 。command列，顯示當前連接的執行的命令，一般就是休眠（sleep），查詢（query），連接（connect）。time列，此這個狀態持續的時間，單位是秒。state列，顯示使用當前連接的sql語句的狀態，很重要的列，后續會有所有的狀態的描述，請注意，state只是語句執行中的某一個狀態，一個sql語句，已查詢為例，可能需要經過copying to tmp table，Sorting result，Sending data等狀態才可以完成，info列，顯示這個sql語句，因為長度有限，所以長的sql語句就顯示不全，但是一個判斷問題語句的重要依據。

常見問題：

一般是睡眠連接過多，嚴重消耗mysql服務器資源(主要是cpu, 內存)，并可能導致mysql崩潰。

解決辦法 ：

在mysql的配置my.cnf文件中，有一項wait_timeout參數設置.即可設置睡眠連接超時秒數，如果某個連接超時，會被mysql自然終止。
wait_timeout過大有弊端，其體現就是MySQL里大量的SLEEP進程無法及時釋放，拖累系統性能，不過也不能把這個指設置的過小，否則你可能會遭遇到“MySQL has gone away”之類的問題。
通常來說，把wait_timeout設置為10小時是個不錯的選擇，但某些情況下可能也會出問題，比如說有一個CRON腳本，其中兩次SQL查詢的間隔時間大于10秒的話，那么這個設置就有問題了（當然，這也不是不能解決的問題，你可以在程序里時不時mysql_ping一下，以便服務器知道你還活著，重新計算wait_timeout時間）：

MySQL服務器默認的“wait_timeout”是28800秒即8小時，意味著如果一個連接的空閑時間超過8個小時，MySQL將自動斷開該連接。

然而連接池卻認為該連接還是有效的(因為并未校驗連接的有效性)，當應用申請使用該連接時，就會導致下面的報錯：

The last packet successfully received from the server was 596,688 milliseconds ago.
mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

28800seconds，也就是8小時。

如果在wait_timeout秒期間內，數據庫連接(java.sql.Connection)一直處于等待狀態，mysql就將該連接關閉。這時，你的Java應用的連接池仍然合法地持有該連接的引用。當用該連接來進行數據庫操作時，就碰到上述錯誤。
可以將mysql全局變量wait_timeout的缺省值改大。

查看mysql手冊，發現對wait_timeout的最大值分別是24天/365天(windows/linux)。

比如將其改成30天

mysql> set global wait_timeout=124800;
Query OK, 0 rows affected (0.00 sec)

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com