生产性能抖动

Select大量数据

当缓存页空间满了后，select 大量数据，导致需要把大量的脏页刷入到磁盘中去，才能腾出足够的空间来执行这条语句。
在这种情况下，可能你会发现突然莫名其妙的线上数据库执行某个查询语句就一下子性能出现抖动，平 时只要几十毫秒的查询语句，这次一下子要几秒都有可能，毕竟你要等待大量脏页flush到磁盘，然后语 句才能执行！

循环写磁盘的Redo log

redo log buffer 里面redo log本身会随着各种条件刷入到磁盘的日志文件中去，，比如redo log buffer里的数据超过容量的 一定比例了，或者是事务提交的时候，都会强制buffer里的redo log刷入磁盘上的日志文件。
磁盘上也是有多个日志文件的，会依次不停的写，如果日志文件都写满了，会回到第一个日志文件再次写入，说以是不停的循环写的。日志文件在写满的情况下，也会触发一次脏页更新。

假设第一个日志文件的redo log 对应的内存里的缓存页的数据都没有刷新到磁盘上的数据页里去，一旦把第一个日志文件里的redo log 被覆盖写了其他日志，那么数据库崩溃时，之前更新的数据就会彻底丢失。

所以一旦把磁盘的日志文件写满了，第一个日志文件被覆盖写的时候，会判断对应的redo log 对应的更新的缓存页是否刷入磁盘，如果没有，则必然要把马上被覆盖写的redo log 更新的缓存页都刷入磁盘。

尤其是在这一种刷脏页的情况下，因为redo log所有日志文件都写满了，此时会导致数据库直接hang 死，无法处理任何更新请求，因为执行任何一个更新请求都必须要写redo log，此时你需要刷新一些脏 页到磁盘，然后才能继续执行更新语句，把更新语句的redo log从第一个日志文件开始覆盖写

所以此时假设你在执行大量的更新语句，可能你突然发现线上数据库莫名其妙的很多更新语句短时间内 性能都抖动了，可能很多更新语句平时就几毫秒就执行好了，这次要等待1秒才能执行完毕。

因此遇到这种情况，你必须要等待第一个日志文件里部分redo log对应的脏页都刷入磁盘了，才能继续 执行更新语句，此时必然会导致更新语句的性能很差。

所以综上所述，导致线上数据库的查询和更新语句莫名其妙出现性能抖动，其实就很可能是上述两种情 况导致的执行语句时大量脏缓存页刷入磁盘，你要等待他们刷完磁盘才能继续执行导致的。

优化方案：

减少缓存页flush到磁盘的概率

那你想要减少缓存页flush到磁盘的频率，这个是很困难的，因为平时你的缓存页就是正常的在被使用， 迟早会被填满，一旦填满，必然你执行下一个SQL会导致一批缓存页flush到磁盘，这个很难控制，除非 你给你的数据库采用大内存机器，给buffer pool分配的内存空间大一些，那么他缓存页填满的速率低一 些，flush磁盘的频率也会比较低。

尽量提升缓存页flush到磁盘的速度 - 刷盘快一点

通常给大家的一个建议就是对于数据库部署的机器，一定要采用SSD固态硬盘，而 不要使用机械硬盘，因为SSD固态硬盘最强大的地方，就是他的随机IO性能非常高。

fulsh缓存页到磁盘，就是典型的随机IO，需要在磁盘上找到各个缓存页所在的随机位置，把数据写 入到磁盘里去。所以如果你采用的是SSD固态硬盘，那么你flush缓存页到磁盘的性能首先就会提高不 少。

光是用SSD还不够，因为你还得设置一个很关键的参数，就是数据库的innodb_io_capacity，这 个参数是告诉数据库采用多大的IO速率把缓存页flush到磁盘里去的。
假设你SSD能承载的每秒随机IO次数是600次，结果呢，你把数据库的innodb_io_capacity 就设置为了300，也就是flush缓存页到磁盘的时候，每秒最多执行300次随机IO，那你不是速度很慢 么，而且根本没把你的SSD固态硬盘的随机IO性能发挥出来！
所以通常都会建议大家对数据库部署机器的SSD固态硬盘能承载的最大随机IO速率做一个测试，这个可 以使用fio工具来测试 ，设置最大值即可。

但是实际flush的时候，其实他会按照innodb_io_capacity乘以一个百分比来进行刷磁盘，这个百分比就 是脏页的比例，是innodb_max_dirty_pages_pct参数控制的，默认是75%，这个一般不用动 。