mysql经常占用cpu100%以上，该怎么解决

有多个原因可至CPU高占用，当访问数量非常高的时候，安装程序没有完成，自身的更新进行过程，都会发生。

可将网络断开，让数据库在无访问情况下，看占用高不高，

再就是大的访问量的情况，如果是此原因引起的，那只能优化访问的语句，降低访问次数，我也见过一些人，无限制地任意使用SQL语句，至数据库负荷重。

不要用SQL，用一般的查询语句即可。

查询对象是用来 *** 作数据库中的记录对象。利用它可以按照一定的条件或准则从几个表中筛选出需要 *** 作的字段，并可以把它们集中起来，形成动态数据集。用户可以浏览、查询、打印、甚至修改这个动态数据集中的数据。

通过查询，可以查找和检索满足指定条件的数据，包括几个表中的数据。也可以使用查询同时更新或删除几个记录，以及对数据执行预定义或自定义的计算。

使用查询可以回答有关数据的特定问题，而这些问题通过直接查看表数据很难解决。可以使用查询筛选数据，执行数据计算和汇总数据，还可以使用查询自动执行许多数据管理任务，并在提交数据更改之前查看这些更改。

查询是对数据结果、数据 *** 作或者这两者的请求。可以使用查询回答简单问题，执行计算、合并不同表中的数据，甚至添加、更改或删除表数据。用于从表中检索数据或进行计算的查询叫做选择查询，用于添加、更改或删除数据的查询叫做 *** 作查询。

ž还可以使用查询为窗体或报表提供数据。在设计良好的数据库中，要使用窗体或报表显示的数据通常位于几个不同的表中，通过使用查询，可以在设计窗体或报表之前组合要使用的数据。

一般是睡眠连接过多，严重消耗mysql服务器资源(主要是cpu, 内存)，并可能导致mysql崩溃。

解决办法 ：

mysql的配置myini文件中，有一项：

wait_timeout, 即可设置睡眠连接超时秒数，如果某个连接超时，会被mysql自然终止。

wait_timeout过大有弊端，其体现就是MySQL里大量的SLEEP进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可能会遭遇到“MySQL has gone away”之类的问题，通常来说，我觉得把wait_timeout设置为10是个不错的选择，但某些情况下可能也会出问题，比如说有一个CRON脚本，其中两次SQL查询的间隔时间大于10秒的话，那么这个设置就有问题了（当然，这也不是不能解决的问题，你可以在程序里时不时mysql_ping一下，以便服务器知道你还活着，重新计算wait_timeout时间）：

mysql> show global variables like 'wait_timeout';

+----------------------------+-------+

| Variable_name | Value |

+----------------------------+-------+

| wait_timeout | 120 |

+----------------------------+-------+

mysql> set global wait_timeout=20;

至此，mysql占用cpu下降了

运行平稳的数据库，如果遇到CPU狂飙，到80%左右，那一定是开发写的烂SQL导致的，DBA首先要保证的是，数据库别跑挂了，所以我们要把那些运行慢的SQL杀死并记录到文件里，以便后面的排查。

这里用到一个工具pt-kill，它可以帮助你。

pt-kill --match-info "^(select|SELECT)" --busy-time 3 --victim all --interval 1 --kill --print --daemonize > /root/killtxt

解释：只把select耗时3秒以上的SQL全部杀死，并打印出来。

先 找到 CPU 高的线程，如果 CPU 高的线程号一直在变，那可能不是单个 SQL 引起的 CPU 消耗，需要用其他方法来辅助分析。找到线程任务processlist 。

可以看到很多有用的信息：

1 可以看到 processlist 中对应这根线程的信息

2 可以找到其在 processlist 中的 ID，这样我们就可以下 kill 命令来结束 SQL

小贴士：

使用 performance_schema 时，需要大家注意 MySQL 使用了多个线程编号，源自于不同视角：

1 PROCESSLIST_ID：在 processlist 中的编号，是使用者视角的编号，使用者可以直接用 kill 命令。

2 THREAD_ID：是 MySQL 内部使用的线程编号，是 MySQL 内部视角的编号。

3 THREAD_OS_ID：是在 *** 作系统上，对应的线程编号，是 *** 作系统视角的编号。

大家使用时需要区分好，不要 kill 错了 SQL。

其他有用的信息，可以看到 SQL 执行的开始时间，正在使用了一张临时磁盘表。

如果开启了 performance_schema 的其他监控项，通过 Thread_ID 关联，可以找到更多信息。

当然，眼下这么明显的坑 SQL，我们 kill 掉就是了。

以上就是关于mysql经常占用cpu100%以上，该怎么解决全部的内容，包括:mysql经常占用cpu100%以上，该怎么解决、如何优化因 MYSQL 读写频繁，负载过高导致的CPU高占用率、mysqld占用CPU过高是什么原因等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！