一.场景

      一条修改SQL语句，正常时候特别快，但是偶尔特别慢，场景很难复现，持续时间短。

产生原因：

• InnoDB处理更新语句时候，只做写日志这个磁盘操作。这个日志叫做redo log（重做日志）
• 在更新内存写完redo log后，返回给客户端，本次更新成功

当内存写满，不得不同步至内存时候，就会比较缓慢

   flush就是内存的数据写入磁盘中

• 脏页：当内存数据页和磁盘数据页不一致的时候
• 干净页：当内存 和磁盘上的数据页的内容一致

二.产生刷脏页的场景

• redo log满了，系统要停止所有更新操作，将checkpoint 往前推进，redo log 留出空间可以继续写。
• 系统内存不足，需要新的内存页，内存不足时候需要淘汰数据页，将脏页写到磁盘中
• MySQL 认为系统“空闲”的时
• MySQL 正常关闭时

前两种情况分析：

• redo log写满了，要刷flush脏页，这种情况InnoDB要尽量避免，系统不再接受更新，所有更新都必须堵住
• 内存不够用了，将脏页写到磁盘，这种情况是常态

InnoDB用缓存池（buffer pool）管理内存，缓存池中的内存页有三种状态：

• 未使用
• 使用了都是干净页
• 使用了但是都是脏页

InnoDB策略时尽量使用内存，对于一个长时间运行的库来说，未被使用 的页面很少

刷脏页是 常态，但是以下会明显影响性能：

1. 要淘汰的脏页太多，导致查询响应时间明显变长
2. 日志写满，更新全部堵住,写性能跌为0

三.InnoDB刷脏页的控制策略 

InnoDB 所在主机的 IO 能力，这样 InnoDB 才能知道需要全力刷脏页的时候，可以刷多快。

    innodb_io_capacity 这个参数

• 值建议设置成磁盘的IOPS
• 磁盘的IOPS可以用fio工具测试