近期一次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，遂找到该进程停掉相关逻辑即可。