1、 更新操作为什么突然变慢
平时的工作中，可能会遇到过这样的场景，一条 SQL 语句，正常执行的时候特别快，但是有时也不知道怎么回事，它就会变得特别慢，并且这样的场景很难复现，它不只随机，而且持续时间还很短。
看上去就像数据库“抖动”了一下，这种情况的可能原因是在刷脏页(flush)，也就是写内存和日志，将内存和日志里的更改记录到磁盘里，然后空出内存或者日志资源。
当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。
根据mysql实战(二) 一条SQL更新语句的执行过程里提到的WAL（先写日志，之后再写磁盘）技术，数据库将随机写转换成了顺序写，大大提升了数据库性能。但是同时也带来上述说的脏页、干净页的问题。
2、触发刷脏页的时机
脏页会被后台线程自动 flush ，也会由于数据页淘汰而触发 flush ，而刷脏页的过程由于会占用资源，可能会让你的更新和查询语句的响应时间长一些。那么什么时候会引发数据库的 flush 过程呢?
第一种场景是，新增数据时，先写日志的日志文件(InnoDB的redo log)写满了，需要擦除一些，才能继续插入数据。这是系统会停下所有更新操作，进行redo log文件的数据擦除工作。
第二种场景是，系统内存不足。当需要新的内存页加载数据时，需要淘汰一些旧的数据页，如果这个数据页是
脏页，就需要先将脏页写入磁盘。第三种场景，系统比较空闲的时候，只要一有机会，就会刷一点脏页。
第四种场景，mysql正常关闭时，会把内存中的脏页都 flush 到磁盘上，这样下次mysql启动时就可以直接从磁盘上读数据，启动速度会很快。
3、频繁刷脏页的处理办法
第三、四种场景下，对系统压力很小，不会有太多“性能”问题。
第一种是“redo log 写满了，要 flush 脏页”，这种情况是 InnoDB 要尽量避免的。因为出现这种情况的时候，整个系统就不能再接受更新了，所有的更新都必须堵住。第二种是“内存不够用了，要先将脏页写到磁盘”，这种情况其实是常态。
刷脏页虽然是常态，但是出现以下这两种情况，都是会明显影响性能的：
- 一个查询要淘汰的脏页个数太多，会导致查询的响应时间明显变长；
- 日志写满，更新全部堵住，写性能跌为 0，这种情况对敏感业务来说，是不能接受的。
所以，InnoDB 需要有控制脏页比例的机制，来尽量避免上面的这两种情况。
InnoDB 脏页的控制策略，是根据 InnoDB 所在主机的 IO 能力， InnoDB 决定刷脏页的时候，要刷多快。
和这些策略相关的配置参数：
-
innodb_io_capacity这个参数它会告诉 InnoDB 你的磁盘能力。这个值我建议你设置成磁盘的 IOPS。磁盘的 IOPS 可以通过 fio 这个工具来测试. -
innodb_max_dirty_pages_pct是脏页比例上限，默认值是 75%，平时要多关注脏页比例，不要让它经常接近 75%。 -
innodb_flush_neighbors参数就是用来控制是否连带刷掉当前脏页附近的“邻居脏页”，值为 1 的时候会有上述的“连坐”机制，值为 0 时表示不找邻居，自己刷自己的。mysql8.0开始，默认值已经是0了。
