本文目录一览：
- 1、MySQL CPU占用过高怎么办
- 2、记一次mysql磁盘io高的问题排查
- 3、mysql中cpu负载很高，是什么原因
- 4、如何定位导致mysql服务器io压力大的进程
- 5、Mysql服务器负载很高，性能问题排查思路是怎样的
- 6、如何查看mysql io高的表
MySQL CPU占用过高怎么办
MySQL CPU占用过高原因主要有以下几种
CPU过时（比较旧的CPU）
RAM资源不足（RAM记忆体）
解决办法如下：
①临时解决方案
首先是ctrl+alt+delete快捷键打开工作管理员
然后找到下方图一中的mysqld.exe
右击移至详细资料
再来右击设定优先顺序
按照下方图二的步骤
根据占用情况调整成低于标准或者低
这个方法只能临时解决
②实际解决方法是更换CPU
总结：根据正常的mysql使用，即使大量数据往来也不会造成CPU占用过高，目前推论应该是CPU比较过时的原因，治标不治本的临时解决方案。
备注：如采取方案②你需要备份你的资料，因为更换CPU会有很大的机会需要重新安装你的作业系统。
记一次mysql磁盘io高的问题排查
现象是，系统里的java连接mysql超时了，
于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况
发现mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系统的负载也到达了50的样子
用mpstat查看cpu情况
好明显，都在等io
用iostat查看io情况，%util的值，一直在80%，99%之间变化
以为磁盘有问题，用dd测下速看看
从上面的结果看，也还好，没问题
以为可能磁盘有坏道，用下面命令也扫了一遍，没问题
结果也没有坏的块，这个过程，很耗时。
用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的
想看看mysql，研究写哪个文件时，最耗时的
从上面结果来看，xxl_job是最耗时的。知道点眉目了，因为公司的定时任务是用的xxljob，定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下
我的天，这个表的记录有千万！！！这些记录，没做定时任务来清理，由于都是一些没用的记录，所以这个表的数据我全清了
清了之后，再用iostat查看
%util一下子就降下来了，用iotop查看mysql进程的io也下降了
cpu的iowait也下降了
定义一个事件，让mysql定时清理30天前的日志记录
记录一下，希望对有需要的朋友也起一点提示
mysql中cpu负载很高，是什么原因
mysql中cpu负载很高，是什么原因
1、确定高负载的类型 htop，dstat命令看负载高是CPU还是IO
看具体是哪个用户哪个进程占用了相关系统资源，当前CPU、内存谁在使用
2、监控具体的sql语句，是insert update 还是 delete导致高负载
抓取mysql包分析，一般抓3306端口的数据 看出最繁忙的sql语句了
3、检查mysql日志
分析mysql慢日志，查看哪些sql语句最耗时
检查mysql配置参数是否有问题，引起大量的IO或者高CPU操作
innodb_flush_log_at_trx_commit 、innodb_buffer_pool_size 、key_buffer_size 等重要参数
4、检查硬件问题
如何定位导致mysql服务器io压力大的进程
1.你可以在root账户下，运行iostat,vmstat,查询看看。
分析磁盘IO，要用到两个命令：iostat 和 sar。
iostat -d -x 10 3
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
主要字段含义如下：
r/s 每秒读操作数。
w/s 每秒写操作数。
rsec/s 每秒从设备读取的扇区数量。
wsec/s 每秒向设备写入的扇区数量。
avgrq-sz I/O 请求的平均扇区数。
avgqu-sz I/O 请求的平均队列长度。
await I/O 请求的平均等待时间，单位为毫秒。
svctm I/O 请求的平均服务时间，单位为毫秒。
%util 处理 I/O 请求所占用的时间的百分比，即设备利用率。
#sar -pd 10 3
输出的主要字段含义如下：
DEV 正在监视的块设备
tps 每秒钟物理设备的 I/O 传输总量
rd_sec/s 每秒从设备读取的扇区数量
wr_sec/s 每秒向设备写入的扇区数量
avgrq-sz I/O 请求的平均扇区数
avgqu-sz I/O 请求的平均队列长度
await I/O 请求的平均等待时间，单位为毫秒
svctm I/O 请求的平均服务时间，单位为毫秒
%util I/O 请求所占用的时间的百分比，即设备利用率
Unix/Linux 系统磁盘 I/O 性能监控自动化脚本示例
2.用iotop可以看到是哪些进程IO占用高，不过需要2.6.20以上的kernel
Mysql服务器负载很高，性能问题排查思路是怎样的
对于包括 mysql 在内的大多数数据库系统而言
性能问题的排查主要有以下方向：
1. 需求的不合理造成的性能问题
比方说，不需要实时更新的内容，被要求做成实时更新
2. 架构的不合理造成的性能问题
比方说，不适合数据库保存的数据，被存放在数据库中
或者，频繁访问但是很少变更的数据，没有做缓存
3. 查询语句的不合理造成的性能问题
比方说，重复执行相同的 SQL 会造成资源浪费
或者，大量复杂的 join 语句会导致查询效率低下
4. 数据库设计的不合理造成的性能问题
比方说，盲目追求三范式、四范式，有时候并没有必要
5. 硬件配置的不合理造成的性能问题
比方说，数据库服务器的 io 性能、CPU 、网络状况，都会影响性能
以上这些都是性能问题定位和调优的方向
如何查看mysql io高的表
IO过高是指输入输出过高了这个有许多原因都会导致mysqlIO过高了，小编见过apache处理数据缓存导致mysqlIO过高问题当然也有其它关于mysql本身问题导致mysqlIO过高的问题了，下面给各位整理总结一下关于mysqlIO过高处理办法。
scriptec(2);/script
1、日志产生的性能影响:
由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。MySQL的日志包括错误日志（ErrorLog），更新日志（UpdateLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。当然，更新日志是老版本的MySQL才有的，目前已经被二进制日志替代。
在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。有时候为了进一步的性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。
一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。
2、mysql内执行如下指令：
set global sync_binlog=500;
当每进行500次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
set global innodb_flush_log_at_trx_commit=2;
默认值1代表每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设置为2代表不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值设置为2只会在整个操作系统宕机时才可能丢数据。
注：重新开机后，该指令失效。可在服务启动时，设置如上两项。