分析思路----MySQL服务器io很高

iostat命令——————怎么看懂 IO 指标？

检查 IO 的问题会使用iostat这个命令，这里展示一下命令的效果（iostat -x -k 2 10）

avg-cpu 是 CPU 相关的指标，判断 IO 问题时可以关注 %iowait，其他指标的意义如下：

• r/s 和 w/s：合并后读请求和写请求的每秒请求数，可类似认为是IOPS 。
• rMB/s 和 wMB/s：磁盘的读写吞吐量。
• rrqm/s 和 wrqm/s：每秒合并的读请求和写请求数量。
• %rrqm 和 %wrqm：合并的读请求和写请求百分比。
• r_await 和 w_await：读和写请求的平均响应时间，包含真正的处理时间和队列中的等待时间，ms。
• aqu-sz：平均队列深度。
• rareq_sz 和 wareq_sz：一个读请求和写请求的平均物理大小（KB）。
• scvtm：计算出来的平均 IO 响应时间，目前已经不准确，不用再关注。
• %util：如果使用了 RAID 或者 SSD，则忽略这个指标，仅在单块机械盘上准确。

对于机械盘只关注%util参数即可，在繁忙的系统上，可能此参数达到90%，一般在正常情况下在70%左右即视为成为性能瓶颈。

MySQL与io相关的参数

innodb_io_capacity ：
InnoDB后台任务可用的 IOPS 量。单位是页，当在频繁写操作的时候才有意义,最系统可以支持多大的 IOPS进行调整。SAS 200~1000 ，SSD 2000~5000 ，PCI-E 10000-50000

innodb_io_capacity_max ：
如果刷新活动落后，InnoDB可以更积极地刷新，每秒的I/O操作率（IOPS）高于innodb_io_capacity变量定义。 此变量定义了在这种情况下InnoDB后台任务执行的最大IOPS数量。

innodb_flush_log_at_trx_commit和sync_binlog
控制事务的提交策略和二进制日志落盘策略。都为1为安全的设置。

innodb_buffer_pool_size：
innodb的内存池大小，建议内存的50%-60%

innodb_log_file_size：
日志组中每个日志文件的大小（以字节为单位）。应对于redo log过小造成io频繁的问题。redo log 刷新缓存，建议4M-16M。

innodb_max_dirty_pages_pct：
脏页占Innodb_buffer_pool的比例，，超过时触发刷脏页到磁盘，建议25%-50%。

io过高的原因

1. 瞬时写入数据量过大
   可以通过监控看，如果所有的数据每隔一定周期一起写入数据库，瞬间数据量过于庞大。磁盘IO脉冲式增加。可能也会造成尖刺。

2. 二进制日志文件mysqlbinlog过大

3. 参数不合理