一．排查占用I/O高的进程
Windows
1.打开任务管理器查看较占资源的进程.
2.资源监视器-磁盘-按读、写排序进一步核查：
Linux
1. 运行top命令查看较占资源的进程.
参数：78.2%wa ：表示cpu 中出现严重硬件i/o等待问题，通常就是读写磁盘 I/O 造成的
2. 使用iotop命令进一步核查
二．对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检查、处理方向：
数据库查询慢之mysql优化建立索引案例：
4. 因网站访问大引起mysql占资源问题：根据网站访问日志具体分析处理，如对请求较大的异常IP，useragent进行拦截。
5. (重点)优化innodb格式表数据库配置：修改mysql配置文件修改或添加以下参数就能解决mysql 占io的问题：
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,事务日志都刷新到了磁盘永久保存了；
