【mysql】Innodb三大特性之insert buffer

标签：

一、什么是insert buffer

insert buffer是一种特殊的数据结构（B+ tree）并不是缓存的一部分，而是物理页，当受影响的索引页不在buffer pool时缓存 secondary index pages的变化，当buffer page读入buffer pool时，进行合并操作，这些操作可以是 INSERT, UPDATE, or DELETE operations (DML)

最开始的时候只能是insert操作，所以叫做insert buffer，现在已经改叫做change buffer了

insert buffer 只适用于 non-unique secondary indexes 也就是说只能用在非唯一的索引上，原因如下

1、primary key 是按照递增的顺序进行插入的，异常插入聚族索引一般也顺序的，非随机IO

2 写唯一索引要检查记录是不是存在，所以在修改唯一索引之前,必须把修改的记录相关的索引页读出来才知道是不是唯一、这样Insert buffer就没意义了，要读出来(随机IO)

所以只对非唯一索引有效

二、insert buffer的原理

对于为非唯一索引，辅助索引的修改操作并非实时更新索引的叶子页，而是把若干对同一页面的更新缓存起来做，合并为一次性更新操 作，减少IO，转随机IO为顺序IO,这样可以避免随机IO带来性能损耗，提高数据库的写性能

具体流程

先判断要更新的这一页在不在缓冲池中

a、若在，则直接插入；

b、若不在，则将index page 存入Insert Buffer，按照Master Thread的调度规则来合并非唯一索引和索引页中的叶子结点

Master Thread的调度规则

a、主动merger[innodb主线程定期完成，用户线程无感知]    

主动merge通过innodb主线程(svr_master_thread）判断：若过去1s之内发生的I/O小于系统I/O能力的5%，则主动进行一次insert buffer的merge操作。merge的页面数为系统I/O能力的5%，读取采用async io模式。每10s,必定触发一次insert buffer meger操作。meger的页面数仍旧为系统 I/O能力的5%。

1）主线程发出async io请求，async读取需要被merge的索引页面
2）I/O handler 线程，在接受到完成的async I/O之后，进行merge

b 、被动merge[用户线程完成，用户能感受到meger操作带来的性能影响]

1） insert操作，导致页面空间不足，需要分裂(split)。由于insert buffer只针对单个页面，不能buffer page split[页已经在内存里]，因此引起页面的被动meger。同理，update操作导致页面空间不 足；purge导致页面为空等。总之,若当前操作引起页面split or merge，那么就会导致被动merge；

2） insert操作，由于其它各种原因，insert buffer优化返回false，需要真正读取page时，要进行被动merge。与一不同的是，页在disk上，需要读取到内存里；

3）在进行insert buffer操作，发现insert buffer太大，需要压缩insert buffer，这时需要强制被动merge，不允许 insert 操作进行。

三、insert buffer的内部实现

1、insert buffer的数据结构是一棵B+树，在MySQL4.1之前的版本中每张表都有一棵insert buffer B+树

MySQL4.1之后，全局只有一棵insert buffer B+树，负责对所有的表的辅助索引进行 insert buffer。这棵B+树存放在共享表空间中，默认也就是ibdata1中。因此，试图通过独立表空间ibd文件恢复表中数据时，往往会导致check table 失败。这是因为表的辅助索引中的数据可能还在insert buffer中，也就是共享表空间中。所以通过idb文件进行恢复后，还需要进行repair table 操作来重建表上所有的辅助索引

2、insert buffer的非叶子节点存放的是查询的search key（键值），

其构造包括三个字段：space （4 byte）+ marker（1byte） + offset（4byte） = search key （9 byte ）

space表示待插入记录所在的表空间id，InnoDB中，每个表有一个唯一的space id，可以通过space id查询得知是哪张表；

marker是用来兼容老版本的insert buffer；

offset表示页所在的偏移量。

3、当一个辅助索引需要插入到页（space， offset）时，如果这个页不在缓冲池中，那么InnoDB首先根据上述规则构造一个search key，接下来查询insert buffer这棵B+树，然后再将这条记录插入到insert buffer B+树的叶子节点中

4、对于插入到insert buffer B+树叶子节点的记录，需要根据如下规则进行构造：

space | marker | offset | metadata | secondary index record

启用insert buffer索引后，辅助索引页（space、page_no）中的记录可能被插入到insert buffer B+树中，所以为了保证每次merge insert buffer页必须成功，还需要有一个特殊的页来标记每个辅助索引页（space、page_no）的可用空间，这个页的类型为insert buffer bitmap。

四、insert buffer的缺点

1、可能导致数据库宕机后实例恢复时间变长。如果应用程序执行大量的插入和更新操作，且涉及非唯一的聚集索引，一旦出现宕机，这时就有大量内存中的插入缓冲区数据没有合并至索引页中，导致实例恢复时间会很长

2、在写密集的情况下，插入缓冲会占用过多的缓冲池内存（innodb_buffer_pool），默认情况下最大可以占用1/2，这在实际应用中会带来一定的问题

3、insert buffer 无法进行控制，for different workloads and hardware configuration，特别是在SSD盛行的今天

五、查看insert buffer

mysql> show engine innodb status \G
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
41 inserts, 41 merged recs, 499 merges
Hash table size 3984403, node heap has 967 buffer(s)
14.66 hash searches/s, 64.65 non-hash searches/s
---
LOG
---
Log sequence number 27233311008
Log flushed up to   27233311008
Last checkpoint at  27233310593
0 pending log writes, 0 pending chkp writes
37848626 log i/o‘s done, 1.00 log i/o‘s/second

参考

https://dev.mysql.com/doc/refman/5.5/en/innodb-standard-monitor.html

https://dev.mysql.com/doc/refman/5.5/en/innodb-insert-buffering.html

https://www.percona.com/blog/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/

http://blog.itpub.net/22664653/viewspace-1163838/

【mysql】Innodb三大特性之insert buffer

标签：

原文地址：http://www.cnblogs.com/chenpingzhao/p/4883884.html