[小结]InnoDB体系结构及工做原理
参阅：《innodb存储引擎内幕》
原创文章，会不定时更新，转发请标明出处：http://www.cnblogs.com/janehoo/p/7717041.htmlhtml
1、概述：mysql
innodb的整个体系架构就是由多个内存块组成的缓冲池及多个后台线程构成。缓冲池缓存磁盘数据（解决cpu速度和磁盘速度的严重不匹配问题），后台进程保证缓存池和磁盘数据的一致性（读取、刷新），并保证数据异常宕机时能恢复到正常状态。linux
缓冲池主要分为三个部分：redo log buffer、innodb_buffer_pool、innodb_additional_mem_pool。sql
- innodb_buffer_pool由包含数据、索引、insert buffer ,adaptive hash index,lock 信息及数据字典。
- redo log buffer用来缓存重作日志。
- additional memory pool:用来缓存LRU链表、等待、锁等数据结构。
后台进程分为：master thread，IO thread，purge thread，page cleaner thread。 数据库
- master thread负责刷新缓存数据到磁盘并协调调度其它后台进程。
- IO thread 分为 insert buffer、log、read、write进程。分别用来处理insert buffer、重作日志、读写请求的IO回调。
- purge thread用来回收undo 页
- page cleaner thread用来刷新脏页。
master thread根据服务器的压力分为了每一秒及每十秒的操做。每一秒的操做包括：刷新重作日志、根据过去一秒的磁盘吞吐量来判断是否须要merge insert buffer、根据脏页在缓冲池中占比是否超过最大脏页占比及是否开启自适应刷新来刷新脏页。每十秒的操做包括：根据过去10秒的磁盘吞吐量来刷新脏页，刷新重作日志，回收undo 页，再根据脏页占比是否超过70%刷新定量脏页。windows
innodb总体的体系结构以下图所示：数组
2、innodb内部协调管理缓存
一条SQL进入MySQL服务器，会依次通过链接池模块（进行鉴权，生成线程），查询缓存模块（是否被缓存过），SQL接口模块（简单的语法校验），查询解析模块，优化器模块（生成语法树），而后再进入innodb存储引擎。进入innodb后，首先会判断该SQL涉及到的页是否存在于缓存中，若是不存在则从磁盘读取相应索引及数据页加载至缓存。若是是select语句，读取数据(使用一致性非锁定读)，并将查询结果返回至服务器层。若是是DML语句，读取到相关页，先试图给这个SQL涉及到的记录加锁。加锁成功后，先写undo 页，逻辑地记录这些记录修改前的状态。而后再修改相关记录，这些操做会同步物理地记录至redo log buffer。若是涉及及非惟一辅助索引的更新，还须要使用insert buffer。事务提交时，会启用内部分布式事务，先将SQL语句记录到binlog中，再根据系统设置刷新redo log buffer至redo log，保证binlog与redo log的一致性。提交后，事务会释放对这些记录所加的锁，并将这些修改的记录所在的页放入innodb的flush list中，等待被page cleaner thread刷新到磁盘。这个事务产生的undo page若是没有被其它事务引用(insert的undo page不会被其它事务引用)，就会被放入history list中，等待被purge线程回收。安全
须要注意的是：
a.脏页的刷新采用的是checkpoint机制
b.DML语句不一样undo页的格式也会不一样。insert类型的undo log只记录了主键及对应的主键值，而update、delete则记录了主键及全部变动的字段值
c.一条设计很差的SQL，可能会致使大量的离散读、加载不少冗余的数据页至缓存中服务器
如下为innodb内部各部分的协调管理简图：
3、innodb内部关键技术
checkpoint:
若是咱们有足够大的内存且能够接受漫长的数据库恢复时间的话，那咱们没有必要引入checkpoint机制。checkpoint经过标志redo log不可用，刷新缓存中的脏页，解决内存容量瓶颈，缩短恢复时间。innodb会在四种状况下会触发checkpoint：master thead的定时刷新、LRU列表中没有足够的空闲页时（脏页太多时）、redo log不可用时（async/sync flush checkpoint）及数据库关闭时。checkpoint有两种工做模式sharp checkpoint和 fuzzy checkpoint。通常状况下都是使用fuzzy checkpoint(刷新部分脏页)，只有数据库关闭且设置了innodb_fast_shutdown=1时，才会使用sharp checkpoint(刷新全部脏页回磁盘)。innodb系统日志会根据redo log的生命周期保存四个LSN号。分别是：当前系统LSN最大值、当前已经写入日志文件的最大LSN号、已经刷新到磁盘的数据页的最大LSN、已经写入检查点的LSN，后面的LSN值老是小于等于前面的LSN值。当数据库宕机时，能够经过只恢复检查点的LSN至已经写入到日志文件的最大LSN之间的数据来恢复数据库。须要注意的是当脏页容量触碰到低水位线时，调用async flush checkpoint异步刷新脏页至磁盘，当脏页容量触碰到高水位线时会调用sync flush checkpoint 疯狂刷新脏页，磁盘会很忙，存在IO风暴。低水位线=75%total_redo_log_file_size 高水位线=90%total_redo_log_file_size
insert buffer：
专门为维护非惟一辅助索引的更新设计的。由于innodb的记录是按主键的顺序存放的，因此主键的插入是顺序的，而汇集索引对应的辅助索引的更新则是离散的，为了不大量离散读写，先检查要更新的索引页是否已经缓存在了内存中，若是没有，先将辅助索引的更新都放入缓冲（inset buffer区），等待合适机会（master thread的定时操做，索引块须要被读取时，insert buffer bitmap检测到对应的索引页不够用时）进行insert buffer和索引页的合并。由于辅助索引缓存到insert buffer中时并不会读取磁盘上的索引页，以致于没法校验索引的惟一性，因此不适用惟一辅助索引。innodb中全部的非惟一辅助索引的insert buffer均由同一棵二叉树维护。二叉树的非叶子节点由space（表空间id）+marker（兼容老版本的insert buffer）+offset（在表空间中的位置）构成，叶子节点由space+marker+offset+metadata(进入顺序+类型+标志)+辅助索引构成，进行merge合并时，按顺序进行回放。mysql5.1以后，insert buffer支持change_buffer，还能够缓冲非惟一辅助索引的update\delete操做。insert buffer的二叉树结构是存放在共享表空间中的，因此经过独立表空间恢复表时，执行check table操做会失败，由于辅助索引的数据可能还在insert buffer中，须要经过repair table 重建表上所有的辅助索引。为了保证每次 merge insert buffer成功，表空间中每隔256个连续区就有一个insert buffer bitmap页用来记录索引页的可用空间。insert buffer bitmap页老是处于这个连续区间的第二页，每一个索引页在insert buffer bitmap中占4 bit。能够经过show engine innodb stauts\G;查看insert buffer and adaptive hash index 查看insert buffer的合并数量、空闲页数量、自己的大小、合并次数及索引操做次数。经过索引操做次数与合并次数的的比例能够判断出insert buffer所带来的性能提高。
double write：
由于脏页刷新到磁盘的写入单元小于单个页的大小，若是在写入过程当中数据库忽然宕机，可能会使数据页的写入不完成，形成数据页的损坏。而redo log中记录的是对页的物理操做，若是数据页损坏了，经过redo log也没法进行恢复。因此为了保证数据页的写入安全，引入了double write。double write的实现分两个部分，一个是缓冲池中2M的内存块大小，一个是共享表空间中连续的128个页，大小是2M。脏页从flush list刷新时，并非直接刷新到磁盘而是先调用函数（memcpy），将脏页拷贝到double write buffer中，而后再分两次，每次1M将double write buffer 刷新到磁盘double write 区，以后再调用fsync操做，同步到磁盘。若是应用在业务高峰期，innodb_dblwr_pages_written:innodb_dblwr_writes远小于64:1，则说明，系统写入压力不大。虽然，double write buffer刷新到磁盘的时候是顺序写，但仍是是有性能损耗的。若是系统自己支持页的安全性保障（部分写失效防范机制），如ZFS，那么就能够禁用掉该特性（skip_innodb_doublewrite）。
adaptive hash index：
innodb会对表上的索引页的查询进行监控，若是发现创建hash索引可以带来性能提高，就自动建立hash索引。hash索引的建立是有条件的,首先是一定可以带来性能提高。其次数据库以特定模式的连续访问超过了100次，经过该模式被访问的页的访问次数超过了1/16的记录行数。自适应hash根据B+树中的索引构造而来，只需为这个表的热点页构造hash索引而不是为整张表都构建。一样能够经过show engine innodb status\G中的 insert buffer and adaptive hash index(hash searches/s non-hash searches)查看hash index的使用状况。
刷新邻近页：
innodb进行脏页刷新时，会检查该脏页所在区内是否还存在其它脏页，若是存在则一同刷新，经过AIO，进行IO合并，必定程度上减小了IO压力。可是它也存在一个问题，就是把本来不怎么脏的页也刷新到了磁盘。可能很快这个不怎么脏的页又被读取到缓冲中，又增长了IO的压力。对于普通的机械盘开启这个特性能够带来很大的性能提高，可是若是是读写速度很是高的随机盘，能够关闭这个特性（innodb_flush_neighbors=0）性能反而会更好。（由于对该特性的维护也是须要消耗性能的）
异步IO：
mysql 5.5以前并不支持异步IO，而是经过innodb代码模拟实现。5.5以后开始提供AIO支持。数据库能够连续发出IO请求，而后再等待IO请求的处理结果。异步IO带来的好处就是能够进行IO合并操做，减小磁盘压力。要想mysql支持异步IO还须要操做系统支持，首先操做系统必须支持异步IO，像windows，linux都是支持的，可是 mac osx却不支持。同时在编译和运行时还须要有libaio依赖包。能够经过设置innodb_use_native_aio来控制是否启用这个特性，通常开启这个特性可使数据恢复带来75%的性能提高。
事务：
innodb中一个逻辑事务包含一组物理事务。不论是物理事务仍是逻辑事务，都须要知足ACID特性（原子性，一致性，隔离性，及持久性）。若是一个逻辑事务须要操做多个页，那么它对每一个页的操做会以一个物理事务来进行。物理事务对页进行处理时，先根据页的space_id,page_no找到对应的页，再试图对该页加锁。若是申请加的锁和该页本来已经加上的锁冲突，则进入等待状态。不然直接加锁，并将该页加入到memo动态数组中，以后物理事务就能够访问这个页了。若是对该页进行的是变动操做，那么针对这些操做就会在local buffer中产生redo log record记录。当物理事务提交时，会在redo log record后追加一串结束标志日志来保证物理事务的完整性。物理事务提交后，redo log record会被提交到redo log buffer的块中，一个块的大小是512字节，一个redo log record可能会出如今多个块中，这取决于redo log record的长度（每一个块开始的两个字节记录的是第一个mtr在该段中开始的位置，若是是0，则代表仍是上一个block的同一个mtr）。同时被分配到一个LSN号，LSN号肯定了它在redo log中的位置，这个LSN号也将会被写入到物理事务操做的页的页头中。物理事务提交后，会检查memo数组中的这些页是否被修改，若修改了则将其加入到innodb的flush list中。flush list中只能存放一个关于这个页的记录。若是页没有被修改，则直接释放加在它上面的锁。当逻辑事务提交时，会将redo log buffer以块为单位顺序刷新到redo log中。多个逻辑事务并发时，可能会出现多个逻辑事务的物理事务交叉记录在redo log buffer中。也会出现未提交的逻辑事务的部分物理事务日志持久化在redo log中。但这并不会形成日志重作的时候，重作未提交的逻辑事务。缘由是，虽然重作的时候是以物理事务为单位进行重作，但它会判断该物理事务所在的逻辑事务包含的全部物理事务是否完整，若是不完整，那么该逻辑事务所涉及的全部物理事务都不会重作。物理事务的工做过程，能够很好的解释一个逻辑事务在执行的过程当中是在不断地写redo日志，并且不断地往flush list中加塞脏页的。
innodb还支持内外部分布式事务。分布式事务的实现是：应用经过一个事务管理器实现对多个相同或不一样的数据库实例的事务管理。分布式事务与本地事务的区别是多了一个prepare的阶段，待收到全部节点的赞成信息后再commit或rollback。内部分布式事务最多见的是binlog和innodb存储引擎之间。事务提交时会先写binlog再写redo log，由于有内部分布式事务，在写完binlog宕机的状况下，mysql再重启会先检查准备的uxid事务是否已经提交，若没有则存储引擎层再作一次提交。
MVCC：
多版本并发控制，mysql仅在RC，RR隔离级别下支持MVCC。主要是结合undo log来实现的一个数据的多个版本，保证读不会堵塞写，写也不会堵塞读来提升并发。mvcc下，select操做默认是一致性非锁定读，除非显式给select加in share或for update锁，才会使用一致性锁定读。
多隔离级别：innodb支持四种隔离级别RU\RC\RR\serializable。RU不使用MVCC，读取的时候也不加锁。RC利用MVCC都是读取记录最新的版本，RR利用MVCC老是读取记录最旧的版本，并经过next-key locking来避免幻读，serializable不使用MVCC，读取记录的时候加共享锁，堵塞了其它事务对该记录的更新，实现可串行化。隔离级别越高，维护成本越高，并发越低。RC隔离级别下要求二进制日志格式必须是row格式的，由于RC隔离级别下，不会加gap锁，不能禁止一个事务在执行的过程当中另外一个事务对它的间隙进行操做的状况。这种状况下，对于事务开始的和提交的顺序是先更改后提交，后更改先提交的状况，statement格式的binlog只会是按照事务提交的顺序进行记录。这可能会致使复制环境的slave数据和master数据不一致。经过设置innodb_locks_unsafe_for_binlog=1也可使用statement格式，可是主从数据的一致性无法保证。