Mysql的刷脏页问题

平时的工做中，不知道你有没有遇到过这样的场景，一条 SQL 语句，正常执行的时候特别快，可是有时也不知道怎么回事，它就会变得特别慢，而且这样的场景很难复现，它不仅随机，并且持续时间还很短。

当内存数据页跟磁盘数据页内容不一致的时候，咱们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。

平时执行很快的更新操做，其实就是在写内存和日志，而 MySQL 偶尔“抖”一下的那个瞬间，可能就是在刷脏页（flush）。

那么，什么状况会引起数据库的 flush 过程呢？

第一种场景是InnoDB 的 redo log 写满了，这时候系统会中止全部更新操做，把 checkpoint 往前推动，redo log 留出空间能够继续写。

第二种场景对应的就是系统内存不足。当须要新的内存页，而内存不够用的时候，就要淘汰一些数据页，空出内存给别的数据页使用。若是淘汰的是“脏页”，就要先将脏页写到磁盘。

第三种场景对应的就是 MySQL 认为系统“空闲”的时候。固然，MySQL忙起来但是会很快就能把redo log 记满的，因此要合理地安排时间，即便是忙的时候，也要见缝插针地找时间，只要有机会就刷一点“脏页”。

第四种场景对应的就是 MySQL 正常关闭的状况。这时候，MySQL 会把内存的脏页都 flush 到磁盘上，这样下次 MySQL 启动的时候，就能够直接从磁盘上读数据，启动速度会很快。

接下来，你能够分析一下上面四种场景对性能的影响。

其中，第三种状况是属于 MySQL 空闲时的操做，这时系统没什么压力，而第四种场景是数据库原本就要关闭了。这两种状况下，你不会太关注“性能”问题。因此这里，咱们主要来分析一下前两种场景下的性能问题。

第一种是“redo log 写满了，要 flush 脏页”，这种状况是 InnoDB 要尽可能避免的。由于出现这种状况的时候，整个系统就不能再接受更新了，全部的更新都必须堵住。若是你从监控上看，这时候更新数会跌为 0。

第二种是“内存不够用了，要先将脏页写到磁盘”，这种状况实际上是常态。InnoDB 用缓冲池（buffer pool）管理内存，缓冲池中的内存页有三种状态：

• 第一种是，尚未使用的；
• 第二种是，使用了而且是干净页；
• 第三种是，使用了而且是脏页。

InnoDB 的策略是尽可能使用内存，所以对于一个长时间运行的库来讲，未被使用的页面不多。

而当要读入的数据页没有在内存的时候，就必须到缓冲池中申请一个数据页。这时候只能把最久不使用的数据页从内存中淘汰掉：若是要淘汰的是一个干净页，就直接释放出来复用；但若是是脏页呢，就必须将脏页先刷到磁盘，变成干净页后才能复用。

因此，刷脏页虽然是常态，可是出现如下这两种状况，都是会明显影响性能的：

1. 一个查询要淘汰的脏页个数太多，会致使查询的响应时间明显变长；

2. 日志写满，更新所有堵住，写性能跌为 0，这种状况对敏感业务来讲，是不能接受的。

因此，InnoDB 须要有控制脏页比例的机制，来尽可能避免上面的这两种状况。

InnoDB 刷脏页的控制策略

首先，你要正确地告诉 InnoDB 所在主机的 IO 能力，这样 InnoDB 才能知道须要全力刷脏页的时候，能够刷多快。

这就要用到 innodb_io_capacity 这个参数了，它会告诉 InnoDB 你的磁盘能力。

如今你知道了，InnoDB 会在后台刷脏页，而刷脏页的过程是要将内存页写入磁盘。因此，不管是你的查询语句在须要内存的时候可能要求淘汰一个脏页，仍是因为刷脏页的逻辑会占用 IO 资源并可能影响到了你的更新语句，均可能是形成你从业务端感知到 MySQL“抖”了一下的缘由。

要尽可能避免这种状况，你就要合理地设置 innodb_io_capacity 的值，而且平时要多关注脏页比例(参数 innodb_max_dirty_pages_pct)，不要让它常常接近 75%。