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