InnoDB的Master Thread调度流程

转自：http://ourmysql.com/archives/902 

• HOME
• 关于OURMYSQL
• MYSQL链接
• 感谢

InnoDB的主要IO操作都是在Master Thread（srv0srv.c）中完成的，所以分析InnoDB的IO调度，就一定要分析Master Thread线程。

下面是我画的一张流程图，标识了整个Master Thread的调度流程。红色部分是InnoDB Plugin/XtraDB对原有InnoDB引擎的改进。
每个Process文字中最下面的括号是进行这个操作的具体函数，可以参照源代码阅读本图。

顺便解释一下“插入缓冲”（Insert Buffer）：InnoDB为了避免更新数据时更新索引损失太多性能，使用了这种称为Insert Buffer的方法来缓冲索引更新，对于非聚集索引（主键索引）、唯一索引的修改，不是每次都直接插入索引页，而是先判断要更新的这一页在不在内存中，如果不在则存入Insert Buffer，按照Master Thread的调度规则来合并非唯一索引和索引页中的叶子结点，这样经常能减少更新索引的代价。为什么要求是非唯一索引（排除主键索引和唯一索引）呢？因为唯一索引要检查记录是不是存在，所以必须把修改的记录影响的索引页读出来才知道是不是唯一，这样Insert Buffer就没意义了，反正要读出来，所以只对非唯一索引有效。
show innodb status中的“INSERT BUFFER AND ADAPITIVE HASH INDEX”里面显示了Insert Buffer的效果。

更正一部分，发现在刷新100个赃页后，InnoDB认为刷新耗时已经超过一秒了，无需等待，设置skip_sleep=TRUE，直接跳过os_pthread_sleep，进行下一次判断。

另外：http://blog.csdn.net/wudongxu/article/details/6229552

 在整个过程中主要包括五个子过程：（三种操作：刷新日志缓存到磁盘srv_sync_log_buffer_in_background、合并插入缓存ibuf_contract_for_n_pages、刷新赃页到磁盘buf_flush_batch(BUF_FLUSH_LIST)）

 1. 每1秒做的操作：

•  日志缓冲刷新到磁盘，即使这个事务还没有提交（总是）。
•  合并插入缓冲（可能）。
•  至多刷新100个InnoDB的缓冲池中的脏页到磁盘（可能），如果进行了这个操作之后可能已经超过了1s，所以在下次LOOP的时候不必再sleep 1s。
•  是否开启了adaptive_flush？是的话则刷新buf_flush_get_desired_flush_rate赃页到磁盘。
• 如果当前没有用户活动，切换到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个脏页写入磁盘。

 

2. 每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）的页写入磁盘。

 

 3. 后台操作(background_loop)： 

       若当前没有用户活动（数据库空闲时）或者数据库关闭时，就会切换到这个循环，否则跳到主loop从重新开始。

•  删除无用的Undo页（总是）。
•  合并20个插入缓冲（总是）。

 4. flush_loop：

      若经过了backgroud loop之后当前还是没有用户活动（数据库空闲时）就会进入到这个循环，否则跳到主loop重新开始。

•   不断刷新100个页，直到符合条件（buf_get_modified_ratio_pct() <= srv_max_buf_pool_modified_pct）才跳出
•   产生一个检查点（总是）。

 5. suspend_thread：

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

 

以上五个过程就是master thread的主要过程，自己目前也只是对这个函数一个简单的了解。并没有完全理解为什么会是这样一个过程，以及这个过程中的三种操作的具体实现也还不清楚。这些也是我后期学习的重点，欢迎各位大虾指点。谢谢！