一．排查占用I/O高的进程

Windows

1.打开任务管理器查看较占资源的进程.

2.资源监视器-磁盘-按读、写排序进一步核查：

 

Linux

1. 运行top命令查看较占资源的进程.

 

参数：78.2%wa ：表示cpu 中出现严重硬件i/o等待问题，通常就是读写磁盘 I/O 造成的

2. 使用iotop命令进一步核查

iotop  -o    # 仅显示占用I/O的进程

 

 

二．对mysql占用I/O具体分析

◆ 使用：“show  processlist; ”或 “show full processlist;”命令查看具体语句。

可以看出存在锁表现象

◆  根据具体语句使用explain 执行查看该条语句查询的行数。如果show的时候没有查看到具体语句，可查看my.cnf中是否有开启慢查询日志，通过mysqldumpslow 来分析记录

可以看出执行量大，查询很慢.

◆ 使用：“lsof -p pid号” 或 “ll/proc/pid号/fd ”命令查看读写频繁的数据库、表等。

三．提供解决方案及建议

1. 非ssd磁盘配置的主机首先引导推荐升级为ssd磁盘。

2. 出现锁表现象问题：建议将myisam格式表转换成innodb格式。

3. 查询量大，执行慢的现象问题：检查是否有创建相应的索引，已创建索引是否合理等，检查具体的语句是否需要优化。

   mysql比较占iops检查、处理方向：/list.asp?unid=2222
   数据库查询慢之mysql优化建立索引案例：/list.asp?unid=2802

4. 因网站访问大引起mysql占资源问题：根据网站访问日志具体分析处理，如对请求较大的异常IP，useragent进行拦截。

5. （重点）优化innodb格式表数据库配置：修改mysql配置文件修改或添加以下参数就能解决mysql 占io的问题：

innodb_flush_log_at_trx_commit = 2

innodb_flush_log_at_trx_commit=N的意义：

    innodb_flush_log_at_trx_commit=0 ：每次commit时,事务日志写进了innodb  log buffer , 然后每秒Log Thread  会将事务日志从innodb log  buffer刷新到ib_ogfile(也就刷新到了磁盘）。 当innodb_flush_log_at_trx_commit设置为0，mysqld进程的崩溃会导致 上一秒钟所有事务数据的丢失， 这是因为每次commit，事务日志只是写进了innodb log buffer 中，然后是每秒才将innodb log buffer 中的事务日志刷新到磁盘永久保存， 所以mysqld进程的崩溃时， innodb log buffer可能会有一秒的日志没有刷新出来，但是在这种情况下，MySQL性能最好；

    innodb_flush_log_at_trx_commit=2 ：每次commit时，事务日志写进了innodb  log buffer，并同时接着写进os cache, 也就是说每次commit，事务日志写进了os cache中， 然后每秒从os cache刷新到ib_logfile(也就是刷新到了磁盘）。innodb_flush_log_at_trx_commit设置为2，只有在操作系统崩溃或者系统掉电的情况下， 上一秒钟所有事务数据才可能丢失，因为每次commit，事务日志已经进入了os cache,所以mysqld崩溃，事务日志是不会丢失的；

    innodb_flush_log_at_trx_commit=1 ：这是最安全的设置，同时由于频繁的io操作，导致效率是最差的，这时候不管是mysqld，还是操作系统崩溃，都不会丢数据， 这是因为每次commit,事务日志都刷新到了磁盘永久保存了；