原创

InnoDB体系架构

后台线程

Master Thread

一个非常核心的后台线程,主要负责缓冲区的数据异步刷新到磁盘,保证数据的一致性,包括脏页的刷新,合并插入缓冲(insert Buffer)、UNDO也页的回收

IO Thread

Innodb 1.0以前有四个IO Thread, write、read、insert buffer和log IO Thread。

innodb 1.x开始,read Thread和write Thread分别增加到四个,可以使用下面命令查看

show VARIABLES like 'innodb_%io_threads';

可以通过命令查看来观察InnoDB中的IO Thread:

show ENGINE INNODB STATUS;

Purge Thread

事务被提交后,所使用的undolog可能不再需要,因此需要Purge Thread来回收已经使用并分配的undo页。在innodb 1.1版本以前,purge操作仅在innodb的Master Thread中完成。在innodb 1.1 版本开始,purge操作可以分配到单独的线程中进行,因此来减轻Master Thread的工作,从而提高CPU的使用率以及提升存储引擎的性能。用户可以通过以下配置来启用独立的purge Thead

[mysqld]

Innodb_purge_threads = 1

在innodb1.1版本中,即便Innodb_purge_threads设置大于1,innodb存储引擎在启动时也会将其设置为1,并且有错误的提示。

而在innodb1.2开始,innodb支持多个purge Thread,这样做的目的是为了加快undo页的回收。同时由于purge Thread需要离散的读取undo页,这样也能更进一步利用磁盘的随机读取性能。

Page Cleaner Thread

Page Cleaner Thread 在innodb 1.2 版本引入,其作用就是将之前的脏页刷新操作都放到单独的线程中完成。其目的是为了减轻Master Thread的工作及对用户查询线程的阻塞,进一步提升存储引擎的性能。

内存

缓冲池

innodb存储引擎是基于磁盘存储的,并将其中的记录按照页的方式进行管理。因此可将其视为基于磁盘的数据库系统。在数据库系统中,由于CPU速度与磁盘之间的鸿沟,基于磁盘的数据库系统通常使用缓存池技术来提高数据库的性能。

缓冲池简单来说就是一块内存区域,通过内存的速度来弥补磁盘速度较慢对数据库性能的影响。在数据库中进行读取页的操作,首先将从磁盘读到的页存放到缓冲池中,这个过程被称为将页"FIX"在缓冲池中。下一次读相同的页时,首先判断该页是否在缓冲池中。若在缓冲池中,称该页在缓冲池中被命中,直接读取该页。否则读取磁盘上的页。

对于数据库中的修改操作,则首先修改在缓冲池中的页,然后再以一定的频率刷新到磁盘上。这里需要注意的是,页从缓冲池刷新回磁盘的操作并不是每次发生页变更时触发,而是通过一种成为Checkpoint的机制刷新回磁盘。同样也是为了提高数据库的性能。

综上所述,缓冲池的大小直接影响着数据库的整体性能。由于32位操作系统的限制,在该系统下最多将该值设置为3G。此外用户可以打开操作系统的PAE选项来获取32位操作系统下最大64G内存的支持。随着内存技术的不断成熟,其成本也在不断下降。单条8G内存条变得非常普遍,而PC服务器已经能支持512G内存。因此为了让数据库使用更多的内存,强烈建议数据库服务器都采用64位的操作系统。

对于innodb存储引擎而言,其缓冲池的配置通过参数innodb_buffer_pool_size来设置。我们通过以下命令可以查询数据库设置的innodb_buffer_pool_size 大小。

show VARIABLES like 'innodb_buffer_pool_size';

具体来看,缓冲池缓存的数据类型有:索引页、数据页、undo页、插入缓冲(insert buffer)、自适应哈希索引(adaptive hash index)、innodb存储的锁信息(lock info)、数据库字典(data dictionary)等。不能简单的认为,缓冲池只是缓存索引页和数据页,他们只是占缓冲池的很大一部分而已。下图能很好的显示了innodb存储引擎中内存的结构情况。

LRU List、FREE List和Flush List

在前一小节中我们知道缓冲池是一个很大的区域,其中存放各种类型的页。那么innodb存储引擎是怎么对这么大的内存进行管理的呢?请看下面。

通常来说,数据库的缓冲池是通过LRU(Lastest Recent Userd,最近最少使用)算法来进行管理的。即最频繁使用的页在LRU列表的前端,而最少使用的页在LRU列表的尾端。当缓冲池不能存放新读取到的页时,将首先释放LRU列表的后端的页。

在InnoDB存储引擎中,缓冲池中页的大小默认为16KB,同样使用LRU算法对缓冲池进行管理。稍有不同的是InnoDB存储引擎对传统的LRU算法做了一些优化。在InnoDB的存储引擎中,LRU列表中还加人了midpoint 位置。新读取到的页,虽然是最新访问的页,但并不是直接放人到LRU列表的首部,而是放入到LRU列表的midpoint位置。这个算法在InnoDB存储引擎下称为midpoint insertion strategy。在默认配置下,该位置在LRU列表长度的5/8处。midpoint 位置可由参数innodb_old_blocks_pct 控制,如:

show VARIABLES like 'innodb_old_blocks_pct';

innodb_old_blocks_pct 37

从上面的例子可以看到,参数innodb_old_blocks_pct默认值为37,表示新读取的页插人到LRU列表尾端的37%的位置(差不多3/8的位置)。在InnoDB存储引擎中,把midpoint之后的列表称为old列表,之前的列表称为new列表。可以简单地理解为new列表中的页都是最为活跃的热点数据。那为什么不采用朴素的LRU算法,直接将读取的页放人到LRU列表的首部呢?这是因为若直接将读取到的页放人到LRU的首部,那么某些SQL操作可能会使缓冲池中的页被刷新出,从而影响缓冲池的效率。常见的这类操作为索引或数据的扫描操作。这
类操作需要访问表中的许多页,甚至是全部的页,而这些页通常来说又仅在这次查询操作中需要,并不是活跃的热点数据。如果页被放人LRU列表的首部,那么非常可能将所需要的热点数据页从LRU列表中移除,而在下一次需要读取该页时,InnoDB 存储引擎需要再次访问磁盘。

为了解决这个问题,InnoDB存储引擎引入了另一个参数来进一步管理LRU列表,这个参数是innodb_old_blocks_time, 用于表示页读取到mid位置后需要等待多久才会被加入到LRU列表的热端。因此当需要执行上述所说的SQL操作时,可以通过下面的方法尽可能使LRU列表中热点数据不被刷出。

mysql> SET GLOBAL innodb_ old_ blocks_ time=1000;
Query oK,0 rows affected(0.00sec)

如果用户预估自己活跃的热点数据不止63%,那么在执行SQL语句前,还可以通过下面的语句来减少热点页可能被刷出的概率。

mysql >SET GLOBAL innodb_old_blocks_pct=20;
Query oK,0 rows af fected(0.00sec)

LRU列表用来管理已经读取的页,但当数据库刚启动时,LRU列表是空的,即没有任何的页。这时页都存放在Free列表中。当需要从缓冲池中分页时,首先从Free列表中查找是否有可用的空闲页,若有则将该页从Free列表中删除,放人到LRU列表中。否则,根据LRU算法,淘汰LRU列表末尾的页,将该内存空间分配给新的页。当页从LRU列表的old部分加入到new部分时,称此时发生的操作为page made young,而因为innodb_old_blocks_time的设置而导致页没有从old部分移动到new部分的操作称为page not made young。可以通过命令SHOW ENGINE INNODB STATUS来观察LRU列表及Free列表的使用情况和运行状态。

show ENGINE INNODB STATUS;

通过命令SHOW ENGINE INNODB STATUS可以看到。Free buffers 表示当前Free列表中页的数量,Database pages表示LRU列表中页的数量。可能的情况是Free buffers与Database pages的数量之和不等于Buffer pool size。正如上图所示的那样,因为缓冲池中的页还可能会被分配给自适应哈希索引、Lock信息、InsertBuffer等页,而这部分页不需要LRU算法进行维护,因此不存在于LRU列表中。pages made young显示了LRU列表中页移动到前端的次数,因为该服务器在运行阶段没有改变innodb_old_blocks_time 的值,. 因此not young为0。youngs/s、 non-youngs/s表示每秒这两类操作的次数。这里还有一个重要的观察变量-----Buffer pool hit rate,表示缓冲池的命中率,这个例子中为100%,说明缓冲池运行状态非常良好。通常该值不应该小于95%。若发生Buffer pool hit rate的值小于95%这种情况,用户需要观察是否是由于全表扫描引起的LRU列表被污染的问题。

InnoDB存储引擎从1.0.x版本开始支持压缩页的功能,即将原本16KB的页压缩为1KB、2KB、4KB和8KB。而由于页的大小发生了变化,LRU列表也有了些许的改变。对于非16KB的页,是通过unzip_ LRU列表进行管理的。通过命令SHOW ENGINE INNODB STATUS可以观察到如下内容:

image-20210327142344546

可以看到LRU列表中-共有1539个页,而unzip LRU列表中有156个页。这里需要注意的是,LRU中的页包含了unzip LRU列表中的页。
对于压缩页的表,每个表的压缩比率可能各不相同。可能存在有的表页大小为8KB,有的表页大小为2KB的情况。unzip LRU是怎样从缓冲池中分配内存的呢?首先,在unzip LRU列表中对不同压缩页大小的页进行分别管理。其次,通过伙伴算法进行内存的分配。例如对需要从缓冲池中申请页为4KB的大小,其过程如下:

  1. 检查4KB的unzip_LRU列表,检查是否有可用的空闲页;
  2. 若有,则直接使用;
  3. 否则,检查8KB的unzip_ LRU列表;
  4. 若能够得到空闲页,将页分成2个4KB页,存放到4KB的unzip_ LRU列表;
  5. 若不能得到空闲页,从LRU列表中申请-一个16KB的页,将页分为1个8KB的页、2个4KB的页,分别存放到对应的unzip_LRU列表中。

同样可以通过information schema架构下的表INNODB BUFFER PAGE LRU来观察unzip_LRU列表中的页,如:

07D8D18F1EC8605D4B937EAC2F3C3940

在LRU列表中的页被修改后,称该页为脏页(dirty page),即缓冲池中的页和磁盘上的页的数据产生了不一致。这时数据库会通过CHECKPOINT机制将脏页刷新回磁盘,而Flush列表中的页即为脏页列表。需要注意的是,脏页既存在于LRU列表中,也存在于Flush列表中。LRU列表用来管理缓冲池中页的可用性,Flush列表用来管理将页刷新回磁盘,二者互不影响。

同LRU列表一样,Flush列表也可以通过命令SHOW ENGINE INNODB STATUS来查看,前面例子中Modifieddbpages24673就显示了脏页的数量。information_schema架构下并没有类似INNODB_BUFFER_PAGE_LRU的表来显示脏页的数量及脏页的类型,但正如前面所述的那样,脏页同样存在于LRU列表中,故用户可以通过元数据表INNODB_BUFFER_PAGE_LRU来查看,唯一不同的是需要加入OLDEST_MODIFICATION大于0的SQL查询条件。

重做日志缓冲

InnoDB存储引擎的内存区域除了有缓冲池外,还有重做日志缓冲(redo log buffer)。InnoDB 存储引擎首先将重做日志信息先放人到这个缓冲区,然后按一定频率将其刷新到重做日志文件。重做日志缓冲- -般不需要设置得很大,因为一般情况下每一秒钟会将重做日志缓冲刷新到日志文件,因此用户只需要保证每秒产生的事务量在这个缓冲大小之内即可。该值可由配置参数innodb log buffer size 控制,默认为8MB。

在通常情况下,8MB的重做日志缓冲池足以满足绝大部分的应用,因为重做日志在下列三种情况下会将重做日志缓冲中的内容刷新到外部磁盘的重做日志文件中。

  1. MasterThread每一秒将重做日志缓冲刷新到重做日志文件;
  2. 每个事务提交时会将重做日志缓冲刷新到重做日志文件;
  3. 当重做日志缓冲池剩余空间小于1/2时,重做日志缓冲刷新到重做日志文件。

额外的内存池

额外的内存池通常被DBA忽略,他们认为该值并不十分重要,事实恰恰相反,该值同样十分重要。在InnoDB存储引擎中,对内存的管理是通过一种称为内存堆( heap)的方式进行的。在对一些数据结构本身的内存进行分配时,需要从额外的内存池中进行申请,当该区域的内存不够时,会从缓冲池中进行申请。例如,分配了缓冲池(innodb_buffer_pool),但是每个缓冲池中的帧缓冲(frame buffer)还有对应的缓冲控制对象(buffer control block),这些对象记录了一些诸如LRU、锁、等待等信息,而这个对象的内存需要从额外内存池中申请。因此,在申请了很大的InnoDB缓冲池时,也应考虑相应的增加这个值。

正文到此结束