MySQL InnoDB历史与架构

一、InnoDB存储引擎

InnoDB是事务安全的MySQL存储引擎，设计上采用了类似于Oracle数据库的架构。通常来说，InnoDB存储引擎时OLTP应用中核心表的首选存储引擎。同样，也正是因为InnoDB的存在，才使MySQL数据库变得更有魅力。目前InnoDB属于MySQL默认存储引擎，并且在MySQL 8.0开始，包括元数据表也都是使用InnoDB存储引擎，之前是一直使用MyISAM存储引擎。

InnoDB存储引擎的创始人Heikki Tuuri，1964年出生于芬兰赫尔辛基，与著名的Linux创始人Linus同时芬兰赫尔辛基大学校友，同时MySQL创始人Monty也是芬兰人，很传奇。他在1995年成立Innobase Oy公司并担任CEO。InnoDB最初就由Innobase Oy公司开发，后来被包括在MySQL所有的二进制发行版本中，也是MySQL 5.5.8开始默认的存储引擎。该存储引擎是一个支持ACID事务，行锁设计，支持MVCC功能，提供类似于Oracle风格的一致性非锁定读，支持外键，被设计用来最有效地利用内存和CPU。并且实现了SQL标准的4种隔离级别，其默认级别是REPEATABLE READ。并通过一种被称为netxt-key locking的策略来避免幻读。

其实从时间点上来看，InnoDB存储引擎比MySQL（1996年发布1.0版本）出现的还要早一些，起初InnoDB本身就是作为一个独立数据库而开发的，所以它很多功能是比较完整的。后来在2000年MySQL发布了2.0版本，其默认存储引擎就是ISAM（MyISAM的前身，在MySQL 3.23版本被MyISAM替换掉）；这期间Innobase Oy公司其实是想把InnoDB给卖掉的，但是由于没人买就一直搁置着。由于MySQL发布2.0后在当时影响还是挺大的，并且由于MySQL是一个插件式数据库，就引起了Innobase Oy公司的注意，后来InnoDB创始人就找MySQL谈，希望MySQL把InnoDB当做一个存储引擎合并到MySQL中，很快双方达成协议，2001年InnoDB就被当做第三方存储引擎集成到MySQL数据库中去了。虽然集成到MySQL了，但是当时MySQL还是主推自家的MyISAM存储引擎，一个不支持事务，表级锁的存储引擎；所以当时如果你创建表时不指定InnoDB为表存储引擎时，默认就是使用MyISAM。好在MySQL 5.5.8版本开始就把InnoDB作为默认存储，所以用户就不需要创建表时还指定InnoDB成表存储引擎，为什么不需要呢？这主要是因为Oracle公司再2006年做了一件前瞻性的决定。

在2006年，Oracle公司收购了Innobase Oy公司，拥有InnoDB存储引擎。据说主要是因为在一次数据库大会上，InnoDB展示了一个表压缩功能，这在当时是很了不起的技术；一个开源的，支持事务、行锁、压缩、MVCC功能的存储引擎真正让Oracle公司感受到了威胁。这也导致了MySQL在很长一段时间内（2006-2010）InnoDB的版本没有任何发展，这几年MySQL也过的不是很好。最终在2008年被SUN公司收购，最后SUN被Oracle收购，自然MySQL也就到了Oracle手里。现在Oracle拥有MySQL数据库及InnoDB存储引擎，从Oracle收购MySQL，推出5.6、5.7、8.0几个大版本，做了大量的优化和功能，并且在8.0大量重构了InnoDB存储引擎，性能大幅度提升。可以说目前能大量重构InnoDB存储引擎的人估计也有Oracle官方团队可以了，包括InnoDB创始人目前也在Oracle公司，如果不出现MySQL被闭源的情况，那么Oracle官方MySQL可以说是前途一片大好。相比MariaDB及Percona来说，由于拥有InnoDB和可重构能力，只要Oracle肯去发展MySQL，那么生产使用基本可以不用考虑其他版本MySQL了。MariaDB就是MySQL被Oracle收购后，其创始人Monty fork MySQL又做出来的一个分支，但其还是使用InnoDB存储引擎；除非MariaDB能够有一款跟InnoDB相匹敌的存储引擎，可能会有意想不到的发展，不然就只能在MySQL层做一些复制及优化器的工作了。另外，目前在InnoDB存储引擎的开发团队中，有来自中国科技大学的Calvin Sun，直到现在这个开发团队中有好几位中国人了。

InnoDB存储引擎已经跟随着MySQL进入到了很多大型网站中使用，如Yahoo、Facebook、淘宝等。从MySQL的官方手册还能得知，著名的Internet新闻站点slashdot.org运行在InnoDB上。还有一些其它站点在InnoDB上处理平均每秒800次插入/更新的操作。这些都证明了InnoDB是一个高性能、高可用、高可扩展的存储引擎。

二、InnoDB体系架构

了解完MySQL的体系结构后，现在再看看InnoDB存储引擎的体系架构。下图简单显示了InnoDB的存储引擎体系结构，InnoDB有多个内存块，你可以认为这些内存块组成了一个大的内存池。

• Innodb内存对象

InnoDB存储引擎内存有多个内存块组成，分别是缓冲池、重做日志缓冲池以及额外的内存池。分别由变量innodb_buffer_pool_size、innodb_log_buffer_size、innodb_additional_mem_pool_size的大小决定（调优的参数）。你可以认为这些内存块组成了一个大的内存池，负责如下工作：

1. 维护所有进程/线程需要访问的多个内部数据结构。

2. 缓存磁盘上的数据，方便快速地读取，并且在对磁盘文件的数据进行修改之前在这里缓存。

3. 重做日志（redo log）缓冲，等等。

其中缓冲池是占最大块内存的部分，InnoDB将表的索引和数据进行缓存。缓冲池允许从内存直接处理频繁使用的数据，这加快了处理速度。在专用数据库服务器上，通常将多达80％的物理内存分配给InnoDB缓冲池。因为InnoDB的存储引擎的工作方式总是将数据库文件按页读取到缓冲池，每个页16k默认（innodb_page_size=16k），在MySQL 5.7中增加了32KB和64KB页面大小的支持，之前版本是不允许大于16k的；但你只能在初始化MySQL实例之前进行配置，一旦设置了一个实例的页面大小，就不能改变它，具体看innodb_page_size参数。然后按最近最少使用（LRU）算法来保留在缓冲池中的缓存数据。如果数据库文件需要修改，总是首先修改在缓存池中的页（发生修改后，该也即为脏也），然后再按照一定的频率将缓冲池的脏也刷新到文件中。可以通过show engine innodb status来查看innodb_buffer_pool的具体使用情况（默认是8个缓冲池实例），如下:

在Buffer pool size中可以看到内存池的使用情况，Buffer pool size表明了一共有多少个缓冲帧（buffer frame），每个缓冲帧为16K，所以这里一共分配了63336*16/1024=1G内存的缓冲池。Free buffers表示当前空闲的缓冲帧，Database pages表示已经使用的缓冲帧，Old database pages表示存放不经常修改的数据页（一般占用内存的1/3），Modified db pages表示脏页的数量，这些数据能分析当前数据库的压力值。

根据上图具体来看：

缓冲池（buffer pool）：缓存的数据类型有索引页（index pages）、数据页（data pages）、undo页（undo pages）、插入缓冲（insert buffer）、自适应哈希索引（adaptive hash index）、InnoDB存储的锁信息（lock info）、数据字典信息（data dictionary）等。

日志缓冲（log buffer）：将重做日志（事务日志）信息先放入这个缓冲区，然后按一定频率将其刷新到重做日志文件。该值一般不需要设置为很大，默认情况下每一秒钟就会将重做日志缓冲刷新到日志文件，因为我们只需要保证每秒产生的事务量在这个缓冲大小之内即可。

额外的内存（additional mem pool）：对于管理员来说也是十分重要的，在InnoDB中，对内存的管理是通过一种称为堆（heap）内存的方式进行。在对一些数据结构本身分配内存时，需要从额外的内存池中申请，当该区域的内存不够时，会从缓冲池中申请。Innodb实例会申请缓冲池的空间，但是每个缓冲池中的帧缓冲还有对应的缓冲控制对象，而且这些对象记录了诸如LRU、锁、等待等方面的信息，而这个对象的内存需要从额外内存池中申请。因此当你申请了很大的InnoDB缓冲池时，这个值也应该相应增加。

• InnoDB后台线程

后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。此外，将已修改的数据文件刷新到磁盘文件，同时保证在数据库发生异常情况下InnoDB能恢复到正常运行的状态。

默认情况下，InnoDB存储引擎的后台线程有7个：4个IO thread（insert，log，read，write），1个master thread，1个锁监控线程，1个错误监控线程。其中master thread线程几乎完成了InnoDB存储引擎所有的功能。（后面会详细介绍master thread）

可以使用show engine innodb status查看InnoDB的状态信息，大概包括事务信息、缓冲池信息、行操作信息以及线程信息等。如下摘取了线程信息：

可以看到其中4个IO线程分别是上图中的insert buffer thread、log thread、read thread、write thread。而read thread and write thread线程是由这两个变量innodb_read_io_threads和innodb_write_io_threads来控制，默认各自开启4个线程。然后加起来也就出现上面我们看到的10个线程了。

InnoDB存储引擎的主要工作都是在一个单独的后台线程master thread中完成的，master thread的优先级也最高。 

三、InnoDB关闭与启动

InnoDB存储引擎现在是MySQL数据库的默认存储引擎，所以InnoDB存储引擎的启动和关闭更准确地是指在MySQL实例的启动过程中对InnoDB表存储引擎的处理过程。

在关闭时，参数innoDB_fast_shutdown影响着表的存储引擎为InnoDB的行为。该参数可取值0、1、2。0表示当MySQL关闭时，InnoDB需要完成所有的full purge和merge insert buffer操作，这会需要一些时间，有时甚至需要几个小时来完成。如果在做InnoDB plugin升级，通常需要将这个参数调为0，然后再关闭数据库。1是该参数的默认值，表示不需要完成上述的full purge和merge insert buffer操作，但是在缓冲池中的数据脏页写回磁盘，而是将日志都写入日志文件。这样不会有任何事物会丢失，但是MySQL数据库下次启动时，会执行恢复操作。

当正常关闭MySQL数据库时，下一次启动应该会很正常。但是，如果没有正常地关闭数据库，如用kill命令关闭数据库，在MySQL数据库运行过程中重启了服务器，或者在关闭数据库时将参数innodb_fast_shutdown设为了2，MySQL数据库下次启动时都会对InnoDB存储引擎的表执行恢复操作。

而参数innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。该值默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效恢复时，如数据页发生了corruption时，MySQL数据库可能会宕机，并把错误写入错误日志中。如果在某些情况下，我们可能并不需要执行完整的恢复操作，我们自己知道如何进行恢复。比如正在对一个表执行alter table操作，这时意外发生了，数据库重启时会对InnoDB表执行回滚操作。对于一个大表，这需要很长时间，甚至可能几个小时。这时我们可以自行进行恢复，例如可以把表删除，从备份中重新将数据导入表中，这些操作的速度可能要远远快于回滚操作。

innodb_force_recovery还可以设置6个非零值：1-6。大的数字包含了前面所有小数字的影响，具体情况如下。

1：忽略检查到的corruption页。

2：阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。

3：不执行事务回滚操作。

4：不执行插入缓冲的合并操作。

5：不查看撤销日志（undo log），innodb存储引擎会将未提交的事务视为已提交。

6：不执行前滚操作。

需要注意的是，当设置参数innodb_force_recovery大于0后，可以对表进行select、create、drop操作，但insert、update或者delete这类操作时不允许的。

四、InnoDB版本信息

InnoDB存储引擎从MySQL5.1开始就采用了插件式方式存在于MySQL中，而现在所有的存储引擎都是真正的插件式了。这样设计的好处是，如果发现一个InnoDB存储引擎的BUG，你能做的就是等待MySQL新版本的发布，InnoDB公司本身对此只能通过补丁的形式来解决，你还需要重新编译一次MySQL才行。现在，你可以得到一个新版本的InnoDB，用来替代有BUG的版本。对于新版本的InnoDB你可以把它看着是一个新版本的InnoDB Plugin存储引擎，因为它还带来了一系列新的特性，比如快速索引重建、更好的多核性能、新的页结构、页压缩功能等等。

另外MySQL中查看innodb版本的方法

或

InnoDB在MySQL5.5开始的版本变化：

MySQL 5.5:

直到MySQL 5.6.3的innodb版本为1.2.3，还可以使用上述变量查看。但是从MySQL5.6.11之后InnoDB停止单独版本编号，变量version_innodb的值变成变量version的值，也就是说等同于MySQL版本号，如下：

下面是官方摘取的Innodb版本变更信息：The innodb version number. Staring in 5.6.11，the separate numbering for innodb is discontinued and this value is the same for the version variable.

<参考>

InnoDB存储引擎

https://yq.aliyun.com/articles/583754?spm=a2c4e.11155435.0.0.15f0135eEUSM1J

喜欢 (3)赏

[资助本站您就扫码 谢谢]

分享 (0)