InnoDB 体系结构(上)

这是学习笔记的第 1893 篇文章

我们先来看一下InnoDB的体系结构图。

这个图分为三个部分，上面的是缓存层，中间是线程层，下面是系统文件层。

在每个层里面又会不断的细分，在MySQL里面存储的单位是页，大小是16k。

缓存层是大量的缓存结构，里面大量的数据都是作为缓存，可以提高访问的查取效率。

系统层是相应的数据字典，数据文件和日志文件,其中binlog是MySQL Server层的，放在这里是因为和InnoDB有密切的关系。

其中多线程设计是InnoDB的一大亮点，通过多线程的方式可以把缓存层，系统文件层的操作高效组织起来，使得InnoDB可以提供数据服务。

学习InnoDB需要明确：InnoDB是基于表的存储引擎，明白了这一点，我们后续对InnoDB状态的分析会有本质的差别。

查看InnoDB状态的小技巧

MySQL中如果要查看InnoDB的状态，强烈推荐的方式就是命令show engine innodb status。

对于这个命令，第一段是头部信息，如下：

mysql> show engine innodb status\G

*************************** 1. row *******************

Type: InnoDB

Name:

Status:

=====================================

2019-02-16 09:42:27 0x7f20b0690700 INNODB MONITOR OUTPUT

=====================================

Per second averages calculated from the last 34 seconds

。。。。

内容包括当前的日期和时间，以及自上次输出以来经过的时长

可以从时间和描述看到这个命令的输出不是实时的结果。

当然还有几类查看的方式，比如information_schema中INNODB_XX的数据字典（比如INNODB_BUFFER_POOL_STATS和INNODB_BUFFER_PAGE_LRU）和新版本中的sys schema,里面是可以提供一些InnoDB不同维度的信息，但是相比而言，show engine innodb status命令的输出要丰富的多。

目前来看似乎没有专门的工具来解读命令 show engine innodb status的输出信息，在没有这些报告工具之前，我们要读取InnoDB的状态毫无疑问是命令的方式来触发，很多时候我们是执行了命令，然后上下翻屏幕去找相应的信息，很显然这些内容我们没有保留下来，show engine innodb status的结果不是实时的，如果要想查看上一次的命令结果该怎么办呢，有一个小技巧。

我们是通过mysqld的进程号在系统层面来找到句柄的信息。

首先查看mysqld的进程号。

# ps -ef|grep mysqld|grep -v grep

root 2122 1 0 19:54 ? 00:00:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/data/mysql --pid-file=/data/mysql/dev01.pid

mysql 2382 2122 0 19:54 ? 00:00:13 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/mysqld.log --pid-file=/data/mysql/dev01.pid --socket=/tmp/mysql.sock

在这里就是找mysqld的进程号，即2382

在操作系统层面我们来看下句柄的信息，可以看到输出了一个列表。

# ll /proc/2382/fd|grep deleted

lrwx------ 1 root root 64 Sep 12 23:29 11 -> /tmp/ibq9KpG4 (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 4 -> /tmp/ibuuKHaH (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 5 -> /tmp/ibET4ZCa (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 6 -> /tmp/ib4nyi5D (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 7 -> /tmp/ib1XzG2A (deleted)

在这么多的文件里，我们看到文件都是序号，会映射到指定目录下面。

那么那个文件才是我们要找的呢？我们通过lsof来间接印证。

可以看到会根据lsof的方式来输出句柄信息。

# lsof -c mysqld|grep deleted

mysqld 2382 mysql 4u REG 253,0 3942 1576539 /tmp/ibuuKHaH (deleted)

mysqld 2382 mysql 5u REG 253,0 0 1576540 /tmp/ibET4ZCa (deleted)

mysqld 2382 mysql 6u REG 253,0 0 1576541 /tmp/ib4nyi5D (deleted)

mysqld 2382 mysql 7u REG 253,0 0 1576542 /tmp/ib1XzG2A (deleted)

mysqld 2382 mysql 11u REG 253,0 0 1576543 /tmp/ibq9KpG4 (deleted)

需要注意第7列，这是唯一一个句柄内容非空的，在这个场景里就是show engine innodb status的输出结果，即文件/tmp/ibuuKHaH映射到的4号文件。

# ll 4

lrwx------ 1 root root 64 Sep 12 23:29 4 -> /tmp/ibuuKHaH (deleted)

如果要查看命令的完整内容，则需要查看的就是4号文件。

# cat 4

=====================================

2018-09-12 23:28:26 0x7f8e7bf74700 INNODB MONITOR OUTPUT

=====================================

Per second averages calculated from the last 22 seconds

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 6 srv_active, 0 srv_shutdown, 12793 srv_idle

srv_master_thread log flush and writes: 12799

。。。。

后续可以基于这些内容来做更多的定制和解析。

InnoDB的多线程技术

前面说到了InnoDB是多线程设计，那么在报告中如何体现呢。

我们需要聊一下InnoDB的后台线程，可以使用如下的脑图来解释

InnoDB的线程主要分为4类，Master Thread,IO Thread,Purge Thread,Page Cleaner Thread

Master Thread是InnoDB的核心线程，早期的很多事情都是它来做的，算是一个全栈线程，后来逐步做了拆分，自MySQL5.5开始引入了purge thread,将purge 任务从master线程中独立出来，自MySQL 5.6.2开始引入了Page cleaner thread.

这些线程的作用和描述如下：

可能看到这里还不够清晰，我们可以记住我们的小目标，通过命令来匹配信息：

其中Master Thread的信息在命令输出中如下：

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 21 srv_active, 0 srv_shutdown, 91981 srv_idle

srv_master_thread log flush and writes: 92002

这是一个测试环境的输出结果，没有什么负载，其中srv_master_thread loops是Master线程的循环次数，每次循环时会选择一种状态（active,shutdown,idle）执行,其中Active数量增加与数据变化有关，与查询无关，可以通过srv_active和srv_idle的差异可以看出，通过对比active和idle的值，来获得系统整体负载情况，如果Active的值越大，证明服务越繁忙。

一个相对比较繁忙的数据库的输出如下，可以看到Active的数据远远高于idle：

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 14921578 srv_active, 0 srv_shutdown, 277461 srv_idle

srv_master_thread log flush and writes: 15199037

而对于IO thread相对简单清晰一些，它们都是异步IO请求，在日志里面已经很清楚了，我们可以看到相关的IO线程和数量：

FILE I/O

--------

I/O thread 0 state: waiting for completed aio requests (insert buffer thread)

I/O thread 1 state: waiting for completed aio requests (log thread)

I/O thread 2 state: waiting for completed aio requests (read thread)

I/O thread 3 state: waiting for completed aio requests (read thread)

I/O thread 4 state: waiting for completed aio requests (read thread)

I/O thread 5 state: waiting for completed aio requests (read thread)

I/O thread 6 state: waiting for completed aio requests (write thread)

I/O thread 7 state: waiting for completed aio requests (write thread)

I/O thread 8 state: waiting for completed aio requests (write thread)

I/O thread 9 state: waiting for completed aio requests (write thread)

其中read thread默认4个，write thread默认4个，log thread和insert buffer thread各1个，read和wrtie线程都可以根据参数进行调整。。

对于Purge thread,默认会开启4个线程，提高了回收效率，但是也会带来一些副作用，MySQL对于空间重用机制和Oracle等数据库不同，如果执行了truncate和drop操作，因为开启了多个purge thread去回收空间，随着时间的推移会使得数据恢复的难度大大增加。

而对于Page Cleaner thread,默认值为1，如果在MySQL日志中看到如下的信息，说明我们的Cleaner Thread需要调整一下了。

2019-02-14T23:50:00.501209Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 28469710ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)