近期一次mysql机器io过高导致入库缓慢，这里记录下解决和问题查找的过程。

首先通过top看到wa比较高，wa意思是CPU花在等待IO上的时间占比， 进而通过iostat -x 2看到如下图，

rrqm/s:   每秒进行 merge 的读操作数目.即 delta(rmerge)/s
wrqm/s:  每秒进行 merge 的写操作数目.即 delta(wmerge)/s
r/s:           每秒完成的读 I/O 设备次数.即 delta(rio)/s
w/s:         每秒完成的写 I/O 设备次数.即 delta(wio)/s
rsec/s:    每秒读扇区数.即 delta(rsect)/s
wsec/s:  每秒写扇区数.即 delta(wsect)/s
rkB/s:      每秒读K字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
wkB/s:    每秒写K字节数.是 wsect/s 的一半.(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
await:    平均每次设备I/O操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
svctm:   平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
%util:      一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的.即 delta(use)/s/1000 (因为use的单位为毫秒)


这显然是不正常的，通过iotop命令找到是哪个进程占用了IO

大量的mysql操作，show processlist可以看到几乎没有sql在运行，究竟是什么操作影响了io，想到了查看binlog找出当前正在执行的sql，找到指定时间的binlog，查看其内容

 mysqlbinlog  --start-datetime="2015-3-14 20:15:23" --stop-datetime="2015-3-14 20:30:23"  –base64-output=DECODE-ROWS -v mysql-bin.000002 >tmp.sql

找出里面大量的H5测试日志插入sql，遂找到该进程停掉相关逻辑即可。