[小结]InnoDB体系结构及工作原理

一、概述innodb的整个体系架构就是由多个内存块组成的缓冲池及多个后台线程构成。缓冲池缓存磁盘数据解决cpu速度和磁盘速度的严重不匹配问题后台进程保证缓存池和磁盘数据的一致性读取、刷新并保证数据异常宕机时能恢复到正常状态。缓冲池主要分为三个部分redolog buffer、innodb_buffer_pool、innodb_additional_mem_pool。innodb_buffer_pool由包含数据、索引、insert buffer ,adaptive hash index,lock 信息及数据字典。redo log buffer用来缓存重做日志。additional memory pool:用来缓存LRU链表、等待、锁等数据结构。后台进程分为master threadIO threadpurge threadpage 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%刷新定量脏页。innodb整体的体系结构如下图所示二、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内部各部分的协调管理简图三、innodb内部关键技术checkpoint:如果我们有足够大的内存且可以接受漫长的数据库恢复时间的话那我们没有必要引入checkpoint机制。checkpoint通过标志redo log不可用刷新缓存中的脏页解决内存容量瓶颈缩短恢复时间。innodb会在四种情况下会触发checkpointmaster thead的定时刷新、LRU列表中没有足够的空闲页时脏页太多时、redo log不可用时async/sync flush checkpoint及数据库关闭时。checkpoint有两种工作模式sharp checkpoint和 fuzzy checkpoint。一般情况下都是使用fuzzy checkpoint(刷新部分脏页)只有数据库关闭且设置了innodb_fast_shutdown1时才会使用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_sizeinsert buffer专门为维护非唯一辅助索引的更新设计的。因为innodb的记录是按主键的顺序存放的所以主键的插入是顺序的而聚集索引对应的辅助索引的更新则是离散的为了避免大量离散读写先检查要更新的索引页是否已经缓存在了内存中如果没有先将辅助索引的更新都放入缓冲inset buffer区等待合适机会master thread的定时操作索引块需要被读取时insert buffer bitmap检测到对应的索引页不够用时进行insert buffer和索引页的合并。因为辅助索引缓存到insert buffer中时并不会读取磁盘上的索引页以至于无法校验索引的唯一性所以不适用唯一辅助索引。innodb中所有的非唯一辅助索引的insert buffer均由同一棵二叉树维护。二叉树的非叶子节点由space表空间idmarker兼容老版本的insert bufferoffset在表空间中的位置构成叶子节点由spacemarkeroffsetmetadata(进入顺序类型标志)辅助索引构成进行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 indexinnodb会对表上的索引页的查询进行监控如果发现建立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_neighbors0性能反而会更好。因为对该特性的维护也是需要消耗性能的异步IOmysql 5.5之前并不支持异步IO而是通过innodb代码模拟实现。5.5之后开始提供AIO支持。数据库可以连续发出IO请求然后再等待IO请求的处理结果。异步IO带来的好处就是可以进行IO合并操作减少磁盘压力。要想mysql支持异步IO还需要操作系统支持首先操作系统必须支持异步IO像windowslinux都是支持的但是 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仅在RCRR隔离级别下支持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_binlog1也可以使用statement格式但是主从数据的一致性没法保证。