一条修改SQL语句，正常时候特别快，但是偶尔特别慢，场景很难复现，持续时间短。
产生原因：- InnoDB处理更新语句时候，只做写日志这个磁盘操作。这个日志叫做redo log（重做日志）
- 在更新内存写完redo log后，返回给客户端，本次更新成功
当内存写满，不得不同步至内存时候，就会比较缓慢
flush就是内存的数据写入磁盘中
- 脏页：当内存数据页和磁盘数据页不一致的时候
- 干净页：当内存 和磁盘上的数据页的内容一致
- redo log满了，系统要停止所有更新操作，将checkpoint 往前推进，redo log 留出空间可以继续写。
- 系统内存不足，需要新的内存页，内存不足时候需要淘汰数据页，将脏页写到磁盘中
- MySQL 认为系统“空闲”的时
- MySQL 正常关闭时
- redo log写满了，要刷flush脏页，这种情况InnoDB要尽量避免，系统不再接受更新，所有更新都必须堵住
- 内存不够用了，将脏页写到磁盘，这种情况是常态
InnoDB用缓存池（buffer pool）管理内存，缓存池中的内存页有三种状态：
- 未使用
- 使用了都是干净页
- 使用了但是都是脏页
InnoDB策略时尽量使用内存，对于一个长时间运行的库来说，未被使用 的页面很少
刷脏页是 常态，但是以下会明显影响性能：
- 要淘汰的脏页太多，导致查询响应时间明显变长
- 日志写满，更新全部堵住,写性能跌为0
InnoDB 所在主机的 IO 能力，这样 InnoDB 才能知道需要全力刷脏页的时候，可以刷多快。
innodb_io_capacity 这个参数
- 值建议设置成磁盘的IOPS
- 磁盘的IOPS可以用fio工具测试
