这是学习笔记的第 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 |
是核心的后台线程，主要负责异步刷新和数据一致性处理 |
|
IO Thread |
使用了异步IO模型，负责处理不同类型的IO请求回调 |
innodb_read_io_threadsinnodb_write_io_threads |
Purge Thread |
事务提交后回收已经使用并分配的undo页,线程数从1提高到4，加快标记为废弃undo页的回收速度 |
innodb_purge_threads |
Page Cleaner Thread |
执行buffer pool里面脏页刷新操作,可以进行调整，默认为1，最大为64 |
innodb_page_cleaners |
可能看到这里还不够清晰，我们可以记住我们的小目标，通过命令来匹配信息：
其中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.)