MySQL占用CPU过高,排查原因及解决方案

目录

• 一、mysql中的wait_timeout坑
• 1、第一种修改方式 需重启MySQL(6.5为例)
• 2、第二种修改方式 不需重启MySQL（数据库重启就失效）
• 二、排查有没有地方占用SQL资源过多
• 其中state的状态十分关键
• 总结

一、mysql中的wait_timeout坑

mysql> show variables like '%timeout%';

首先你要明白：

• wait_timeout — 指的是mysql在关闭一个非交互的连接之前所要等待的秒数，其取值范围为1-2147483(Windows)，1-31536000(linux)，默认值28800。
• nteractive_time — 指的是mysql在关闭一个交互的连接之前所要等待的秒数(交互连接如mysql gui tool中的连接)，其取值范围随wait_timeout变动，默认值28800。

所谓的交互式连接，即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。说得直白一点，通过mysql客户端连接数据库是交互式连接，通过jdbc连接数据库是非交互式连接。

MySQL 的默认设置下，当一个连接的空闲时间超过8小时后，一到高峰期肯定会造成，会有太多的TCP连接没关闭，数据库连接数肯定是不够。

从而会产生CPU占用过高，服务器告警等问题。因EPG的一个访问一次对数据库操作量不大，查询完数据就完成ok了，wait_timeout 设置在120s内就很完美了。

1、第一种修改方式 需重启MySQL(6.5为例)

1.1、修改参数配置文件　　 

vi /etc/my.cnf

[mysqld]
wait_timeout = 90
interactive_timeout = 90
#增加以上两列即可，因为官方文档要求修改此参数必须同时修改interactive_timeout

1.2、重启数据库　

service mysqld restart　

或者

/etc/init.d/mysql restart

1.3、查看python数据库参数是否修改成功 

连接MySQL 然后查看 

show variables like ‘wait_timeout';

2、第二种修改方式 不需重启MySQL（数据库重启就失效）

mysql>showvariableslike'%timeout';

　　　　+-------------------------+-------+
　　　　android|Variable_name|Value|
　　　　+-------------------------+-------+
　　　　|connect_timeout|10|
　　　　|delayed_insert_timeout|300|
　　　　|interactive_timeout|开发者_数据库教程200|
　　　　|net_read_timeout|30|
　　　　|net_write_timeout|60|
　　　　|slave_net_timeout|3600|
　　　　|table_lock_wait_timeout|50|
　　　　|wait_timeout|200|
　　　　+-------------------------+-------+

　　mysql>setglobalinteractive_timeout=100;

　　　　QueryOK,0rowsaffected(0.00sec)

退出后重新登录mysql

如果修改interactive_timeout的话wait_timeout也会跟着变，而只修改wait_timeout是不生效的。

二、排查有没有地方占用SQL资源过多

show databases;

3、use  数据库名;         #切换到常用数据库

4、show full processlist;    #显示哪些线程正在运行

或者：

-- select * from information_schema.PROCESSLISTwhere info is not null;

说明各列的含义和用途

• id列: 一个标识，你要kill 一个语句的时候很有用。
• user列:  显示当前用户，如果不是root，这个命令就只显示你权限范围内的sql语句。
• host列: 显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户。
• db列: 显示这ISUCXVuxL个进程目前连接的是哪个数据库。
• command列: 显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）。

 通常代表资源未释放，如果是通过连接池，sleep状态应该恒定在一定数量范围内

 实战范例：因前端数据输出时（特别是输出到用户终端）未及时关闭数据库连接，导致因网络连接速度产生大量sleep连接，在网速出现异常时，数据库too many connections挂死。

简单解读，数据查询和执行通常只需要不到0.01秒，而网络输出通常需要1秒左右甚至更长，原本数据连接在0.01秒即可释放，但是因为前端程序未执行close操作，直接输出结果，那么在结果未展现在用户桌面前，该数据库连接一直维持在sleep状态！

• time列: 此这个状态持续的时间，单位是秒。
• state列: 显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个sql语句，已查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成。
• info列: 显示这个sql语句，因为长度有限，所以长的sql语句就显示不全，但是一个判断问题语句的重要依据。

其中state的状态十分关键

下表列出state主要状态和描述：

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。