master线程的主循环,后台循环,刷新循环,暂停循环

InnoDB存储引擎的主要工作都是在一个单独的后台线程master thread中完成的。master thread的线程优先级别最高。其内部由几个循环（loop）组成：主循环（loop）、后台循环（background loop）、刷新循环（flush loop）、暂停循环（suspend loop）。master thread会根据数据库运行的状态在loop、background loop、flush loop和suspend loop中进行切换。

查看主线程执行的情况：show engine innodb status\G

主循环

loop称为主循环，因为大多数的操作都在这个循环中，其中有两大部分操作：每秒钟的操作和每10秒的操作。

loop循环通过thread sleep来实现，这意味着所谓的每秒一次或每10秒一次的操作是不精确的。在负载很大的情况下可能会有延迟（delay），只能说大概在这个频率下。当然，InnoDB源代码中还采用了其他的方法来尽量保证这个频率。

一秒一次的操作

每秒一次的操作包括：

日志缓冲刷新到磁盘，即使这个事务还没有提交（总是）。
合并插入缓冲（可能）。
至多刷新100个InnoDB的缓冲池中的脏页到磁盘（可能）。
如果当前没有用户活动，切换到background loop（可能）。

即使某个事务还没有提交，InnoDB存储引擎仍然会每秒将重做日志缓冲中的内容刷新到重做日志文件。这一点是必须知道的，这可以很好地解释为什么再大的事务commit的时间也是很快的。

合并插入缓冲（insert buffer）并不是每秒都发生。InnoDB存储引擎会判断当前一秒内发生的IO次数是否小于5次，如果小于5次，InnoDB认为当前的IO压力很小，可以执行合并插入缓冲的操作。

刷新100个脏页也不是每秒都在发生。InnoDB存储引擎通过判断当前缓冲池中脏页的比例（buf_get_modified_ratio_pct）是否超过了配置文件中innodb_max_dirty_pages_pct这个参数（默认为90，代表90%），如果超过了这个阈值，InnoDB存储引擎认为需要做磁盘同步操作，将100个脏页写入磁盘。

十秒一次的操作

每10秒的操作，包括如下内容：

刷新100个脏页到磁盘（可能）。
合并至多5个插入缓冲（总是）。
将日志缓冲刷新到磁盘（总是）。
删除无用的Undo页（总是）。
刷新100个或者10个脏页到磁盘（总是）。
产生一个检查点（总是）。

InnoDB存储引擎会先判断过去10秒之内磁盘的IO操作是否小于200次。如果是，InnoDB存储引擎认为当前有足够的磁盘IO操作能力，因此将100个脏页刷新到磁盘。

InnoDB存储引擎会合并插入缓冲。不同于每1秒操作时可能发生的合并插入缓冲操作，这次的合并插入缓冲操作总会在这个阶段进行。

InnoDB存储引擎会再执行一次将日志缓冲刷新到磁盘的操作，这与每秒发生的操作是一样的。

InnoDB存储引擎会执行一步full purge操作，即删除无用的Undo页。对表执行update、delete这类操作时，原先的行被标记为删除，但是因为一致性读（consistent read）的关系，需要保留这些行版本的信息。但是在full purge过程中，InnoDB存储引擎会判断当前事务系统中已被删除的行是否可以删除，比如有时候可能还有查询操作需要读取之前版本的Undo信息，如果可以，InnoDB会立即将其删除。从源代码中可以发现，InnoDB存储引擎在操作full purge时，每次最多删除20个Undo页。

InnoDB存储引擎会判断缓冲池中脏页的比例（buf_get_modified_ratio_pct），如果有超过70%的脏页，则刷新100个脏页到磁盘；如果脏页的比例小于70%，则只需刷新10%的脏页到磁盘。

InnoDB存储引擎会产生一个检查点（checkpoint），InnoDB存储引擎的检查点也称为模糊检查点（fuzzy checkpoint）。InnoDB存储引擎在checkpoint时并不会把所有缓冲池中的脏页都写入磁盘，因为这样可能会对性能产生影响，而只是将最老日志序列号（oldest LSN）的页写入磁盘。

后台循环

background loop，若当前没有用户活动（数据库空闲时）或者数据库关闭时，就会切换到这个循环。这个循环会执行以下操作：

删除无用的Undo页（总是）。
合并20个插入缓冲（总是）。
跳回到主循环（总是）。
不断刷新100个页，直到符合条件（可能，跳转到flush loop中完成）。

如果flush loop中也没有什么事情可以做了，InnoDB存储引擎会切换到suspend_loop，将master thread挂起，等待事件的发生。若启用了InnoDB存储引擎，却没有使用任何InnoDB存储引擎的表，那么master thread总是处于挂起状态。

master thread的潜在问题

在了解了master thread的具体实现过程后，我们会发现InnoDB存储引擎对于IO其实是有限制的，在缓冲池向磁盘刷新时其实都做了一定的硬性规定（hard coding）。在磁盘技术飞速发展的今天，当固态磁盘出现时，这种规定在很大程度上限制了InnoDB存储引擎对磁盘IO的性能，尤其是写入性能。

磁盘IO的吞吐量

从前面的分析来看，无论何时，InnoDB存储引擎最多都只会刷新100个脏页到磁盘，合并20个插入缓冲。如果是在密集写的应用程序中，每秒中可能会产生大于100个的脏页，或是产生大于20个插入缓冲，此时master thread似乎会“忙不过来”，或者说它总是做得很慢。即使磁盘能在1秒内处理多于100个页的写入和20个插入缓冲的合并，由于hard coding，master thread也只会选择刷新100个脏页和合并20个插入缓冲。同时，当发生宕机需要恢复时，由于很多数据还没有刷新回磁盘，所以可能会导致恢复需要很快的时间，尤其是对于insert buffer。

InnoDB对其进行了修正并发布了补丁。InnoDB存储引擎的开发团队参考了Google的patch，提供了类似的方法来修正该问题。因此InnoDB Plugin开始提供了一个参数，用来表示磁盘IO的吞吐量，参数为innodb_io_capacity，默认值为200。对于刷新到磁盘的数量，会按照innodb_io_capacity的百分比来刷新相对数量的页。规则如下：

在合并插入缓冲时，合并插入缓冲的数量为innodb_io_capacity数值的5%。
在从缓冲区刷新脏页时，刷新脏页的数量为innodb_io_capacity。

如果你使用了SSD类的磁盘，或者将几块磁盘做了RAID，当你的存储拥有更高的IO速度时，完全可以将innodb_io_capacity的值调得再高点，直到符合你的磁盘IO的吞吐量为止。

脏页缓冲池占比

参数innodb_max_dirty_pages_pct的默认值，在MySQL 5.1版本之前（包括5.1），该值的默认值为90，意味着脏页占缓冲池的90%。但是该值“太大”了，因为你会发现，InnoDB存储引擎在每1秒刷新缓冲池和flush loop时，会判断这个值，如果大于innodb_max_dirty_pages_pct，才刷新100个脏页。因此，如果你有很大的内存或你的数据库服务器的压力很大，这时刷新脏页的速度反而可能会降低。同样，在数据库的恢复阶段可能需要更多的时间。

在很多论坛上都有对这个问题的讨论，有人甚至将这个值调到了20或10，然后测试发现性能会有所提高，但是将innodb_max_dirty_pages_pct调到20或10会增加，和Google测试的80比较接近。这样既可以加快刷新脏页的频率，也能保证磁盘IO的负载。

自适应地刷新

InnoDB Plugin带来的另一个参数是innodb_adaptive_flushing（自适应地刷新），该值影响每1秒刷新脏页的数量。原来的刷新规则是：如果脏页在缓冲池所占的比例小于innodb_max_dirty_pages_pct时，不刷新脏页。大于innodb_max_dirty_pages_pct时，刷新100个脏页，而innodb_adaptive_flushing参数的引入，InnoDB存储引擎会通过一个名为buf_flush_get_desired_flush_rate的函数来判断需要刷新脏页最合适的数量。粗略地翻阅源代码后你会发现，buf_flush_get_desired_flush_rate是通过判断产生重做日志的速度来判断最合适的刷新脏页的数量。因此，当脏页的比例小于innodb_max_dirty_pages_pct时，也会刷新一定量的脏页。