记一次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占用过高，一般的原因是索引不当。如果没有索引，顺序查找会带来IO占用高，你现在的IO不高，很可能是order by后面的字句没有索引造成。

mysql可以记录所有执行的SQL语句，但是我们一般记录慢速SQL即可，方法是在my.ini中使用下面的指令：

log-slow-queries

日志是MySQL的重要组成部分，其中对于开发而言不得不关注三种重要的日志，分别是二进制日志（bin log）、事务日志（redo log、undo log）。接下来详细介绍这三种日志。

binlog叫做二进制日志，主要是用于记录MySQL表的逻辑变化过程。在实际应用过程中，通常被用于主从复制和数据恢复。

事务执行过程中，会先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。

事务提交后的写入只是写入到文件系统的page cache，并没有把数据持久化到磁盘。持久化磁盘由 *** 作系统决定调用fsync。

MySQL提供了配置决定fsync的时机，当sync_binlog=0的时候，每次提交事务只写入page cache，不执行fsync。当sync_binlog=1的时候，表示每次提交事务都会执行fsync。当sync_binlog = N的时候，每次提交事务都写入page cache，累计多个事务才进行fsync。

显然，当sync_binlog = 1的时候，binlog日志不会丢失。当sync_binlog = N的时候，如果发生异常重启，会丢失N个事务的binlog日志。

STATEMENT

记录数据 *** 作的原始SQL，可能引发主库备库因索引选择不一致，导致数据执行结果不一致。

ROW

ROW基于行复制，只记录哪条数据被修改.缺点：占空间。比如DELETE 语句，对于STATEMENT只占用1条SQL。而ROW格式则需要把所有记录的数据记录下来。

MIXED

对于可能引发主备不一致的命令使用ROW格式，否则使用STATEMTNT

对于每一次更新 *** 作，MySQL都需要写入磁盘，然后需要找到对应那条记录并更新。IO成本较高和查找成本都很高。为了提高性能，MySQL会将更新 *** 作写入redo log，并更新内存。INNODB引擎会在适当的时候将 *** 作记录更新到磁盘。

[图片上传失败...(image-c6a1f2-1627716309698)]

undo log主要是记录了数据的逻辑变化，比如对应一条insear语句，undo log会记录一条delete语方便回退到更新前的值。

时刻A发生故障的话，由于binlog未写入，redo log回滚数据，两个日志数据是一致的。

时刻B发生故障，则需要判断binlog是否完整来决定如何恢复。

redo log和bin log的区别？

为什么redo log crash-safe，而bin log不可以？

---