超细致的mysql存储引擎——InnoDB的解说-百分百源码网

超细致的mysql存储引擎——InnoDB的解说

发布时间：09/01 来源：未知浏览：关键词：

假如想看本人的数据库默许使用的阿谁储备引擎，可以通过使用命令：

SHOW VARIABLES LIKE 'storage_engine';

一、InnoDB储备引擎

1.InnoDB是事务型数据库的首选引擎

支撑事务平安表（ACID）

事务的ACID属性：即原子性、一致性、隔离性、耐久性

a.原子性：原子性也就是说这组语句要末全部施行，要末全部不施行，假如事务施行到一半显现错误，数据库就要回滚到事务开端施行的地方。

实现：主如果基于MySQ日志系统的redo和undo机制。事务是一组SQL语句，里面有选中，查询、删除等功效。每条语句施行会有一个节点。例如，删除语句施行后，在事务中有个记载留存下来，这个记载中贮存了我们什么时候做了什么事。假如出错了，就会回滚到本来的位置，redo里面已经储备了我做过什么事了，然后逆向施行一遍就可以了。

b.一致性：事务开端前和完毕后，数据库的完全性束缚没有被毁坏。（eg:比方A向B转账，不成能A扣了钱，B却没有收到）

c.隔离性：统一时间，只同意一个事务恳求统一数据，不一样的事务之间彼此没有任何干扰；

假如不思考隔离性则会显现几个问题：

i、脏读：是指在一个事务处置历程里读取了另一个未提交的事务中的数据（当一个事务正在屡次修改某个数据，而在这个事务中这屡次的修改都还未提交，这时一个并发的事务来拜访该数据，就会造成两个事务得到的数据不一致）；（读取了另一个事务未提交的脏数据）

ii、不成反复读：在关于数据库中的某个数据，一个事务范畴内屡次查询却返回了不一样的数据值，这是由于在查询间隔，被另一个事务修改并提交了；（读取了前一个事务提交的数据，查询的都是统一个数据项）

iii、虚读（幻读）：是事务非独立施行时发生的一种现象（eg:事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操纵，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操纵事务T1的会员假如再查看刚刚修改的数据，会发明还有一行没有修改，其实这行是从事务T2中增加的，就仿佛发生幻觉一样）；（读取了前一个事务提交的数据，针对一批数据团体）

d.耐久性：事务完成后，事务对数据库的所有更新将被留存到数据库，不克不及回滚

2.InnoDB是mySQL默许的储备引擎

默许的隔离级别是RR，并且在RR的隔离级别下更近一步，通过多版本并发操纵（MVCC）解决不成反复读问题，加上间隙锁（也就是并发操纵）解决幻读问题。因此InnoDB的RR隔离级别其实实现了串行化级别的结果，而保存了比力好的并发机能。

MySQL数据库为我们供给的四种隔离级别：

a、Serializable（串行化）：可幸免脏读、不成反复读、幻读的发生；

b、Repeatable read（可反复读）：可幸免脏读、不成反复读的发生；

c、Read committed（读已提交）：可幸免脏读的发生；

d、Read uncommitted（读未提交）：最初级别，任何状况都没法包管；

从a----d隔离级别由高到低，级别越高，施行效力越低

3.InnoDB支撑行级锁。

行级锁可以最大程度的支撑并发，行级锁是由储备引擎层实现的。

锁：锁的主要作用是治理同享资源的并发拜访，用于实现事务的隔离性

类型：同享锁（读锁）、独占锁（写锁)

MySQL锁的力度：表级锁（开销小、并发性低），平常在效劳器层实现

行级锁（开销大、并发性高），只会在储备引擎层面停止实现

4、InnoDB是为处置宏大数据量的最大机能设计。

它的CPU效力大概是任何基于磁盘的关系型数据库引擎所不克不及匹敌的

5、InnoDB储备引擎完全与MySQL效劳器整合

InnoDB储备引擎为在主内存中缓存数据和索引而保持它本人的缓冲池。InnoDB将它的表和索引在一个逻辑表空间中，表空间可以包括数个文件（或原始磁盘文件）；

6、InnoDB支撑外键完全性束缚

储备表中的数据时，每张表的储备都依照主键次序存置，假如没有显示在表定义时指定主键。InnoDB会为每一行生成一个6字节的ROWID,并以此作为主键

7、InnoDB被用在众多需要高机能的大型数据库站点上

8、InnoDB中不留存表的行数（eg:select count(*)from table时，InnoDB需要扫描一遍整个表来运算有多少行）；清空整个表时，InnoDB是一行一行的删除，效力非常慢；

InnoDB不创立名目，使用InnoDB时，MySQL将在MySQL数据名目下创立一个名为ibdata1的10MB大小的主动扩展数据文件，乃至两个名为ib_logfile0和ib_logfile1的5MB大小的日志文件

二、InnoDB引擎的底层实现

InnoDB的储备文件有两个，后缀名离别是 .frm和 .idb；其中 .frm是表的定义文件， .idb是表的数据文件。

1、InnoDB引擎采纳B+Tree构造来作为索引构造

B-Tree（均衡多路查寻树）：为磁盘等外储备设备设计的一种均衡查寻树

系统从磁盘读取数据到内存时是以磁盘块位根本单位的，位于统一磁盘块中的数据会被一次性读取出来，而不是按需读取。

InnoDB储备引擎使用页作为数据读取单位，页是其磁盘治理的最小单位，默许page大小是16k.

系统的一个磁盘块的储备空间往往没有那么大，因此InnoDB每次申请磁盘空间时都会是若干地址持续磁盘块来到达页的大小16KB。

InnoDB在把磁盘数据读入到磁盘时会以页为根本单位，在查询数据时，假如一个页中的每条数据都能助于定位数据记载的位置，这将会减少磁盘I/O的次数，提高查询效力。

B-Tree构造的数据可以让系统高效的寻到数据所在的磁盘块

B-Tree中的每个节点按照实际状况可以包括大量的关键字信息和分支，例

每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针储备的是子节点所在磁盘块的地址。

以根节点为例，关键字为17和35，P1指针指向的子树的数据范畴小于17，P2指针指向的子树的数据范畴为17----35，P3指针指向的子树的数据范畴大于35；

模拟查寻关键字29的历程：

a.按照根节点寻到磁盘块1，读入内存。【磁盘I/O操纵第一次】

b.比力关键字29在区间（17,35），寻到磁盘块1的指针P2;

c.按照P2指针寻到磁盘块3，读入内存。【磁盘I/O操纵第二次】

d.比力关键字29在区间（26,30），寻到磁盘块3的指针P2；

e.按照P2指针寻到磁盘块8，读入内存。【磁盘I/O操纵第三次】

f.在磁盘块8中的关键字列表中寻到关键字29.

MySQL的InnoDB储备引擎在设计时是将根节点常驻内存的，因此力求到达树的深度不超越3，也就是I/O不需要超越三次；

剖析上面的结果，发明需要三次磁盘I/O操纵，和三次内存查寻操纵。由于内存中的关键字是一个有序表构造，可以利用二分法查寻提高效力；而三次磁盘I/O操纵时影响整个B-Tree查寻效力的决议因素。

B+Tree

B+Tree是在B-Tree根基上的一种优化，使其更适合实现外储备索引构造，B-Tree中每个节点中有key，也有data，而每一页的储备空间是有限的，假如data数据较大时将会致使每个节点（即一个页）能储备的key的数目很小。当储备的数据量很大时一样会致使B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效力。

在B+Tree中所有数据记载节点都是依照键值大小次序存置在统一层的叶子节点上，而非叶子节点上只储备key值信息，这样可以大大加大每个节点储备的key值数目，落低B+Tree的高度；