结合源码分析show engine innodb status输出内容(一)

show engine innodb status输出内容包括以下几块(我所有试验都是在mysql5.6.22上实现)

background thread
semphores
latest detected deadlock(该部分内容不一定输出，只有在系统出现过死锁情况下才输出)
latest foreign key error(该部分内容不一定输出，只有在系统出现过外键错误情况下才输出)
transactions
file I/O
logs
buffer pool and memory
insert buffer and adaptive hash index
row operations

接下来我将对各个模块输出内容进行解析

1.background thread(后台线程)

图1 background thread 输出

在执行show engine innodb status命令之后，在background thread之前的信息是innodb status相关状态信息，per second averages calculated from the last 29 seconds意思是说接下来的信息，是对过去29秒时间内innodb状态的输出。

Innodb存储引擎室多线程的模型，因此其后台有多个不同的后台线程负责处理不同的任务。Master thread是一个非常核心的后台线程，主要负责缓冲池中的数据异步刷新到磁盘，保证数据的一致性。Master thread具有最高的线程优先级别，其内部由多个循环(loop)组成:主循环，后台循环，刷新循环，暂停循环。

参数	说明
Srv_master_thread loops	Master线程的循环次数，master线程在每次loop过程中都会sleep，sleep的时间为1秒。而在每次loop的过程中会选择active、shutdown、idle中一种状态执行。Master线程在不停循环，所以其值是随时间递增的。
Srv_active	Master线程选择的active状态执行。Active数量增加与数据表、数据库更新操作有关，与查询无关，例如：插入数据、更新数据、修改表等。
Srv_shutdown	这个参数的值一直为0，因为srv_shutdown只有在mysql服务关闭的时候才会增加。
Srv_idle	这个参数是在master线程空闲的时候增加，即没有任何数据库改动操作时。
Log_flush_and_write	Master线程在后台会定期刷新日志，日志刷新是由参数innodb_flush_log_at_timeout参数控制前后刷新时间差。
注:Background thread部分信息为统计信息，即mysql服务启动之后该部分值会一直递增，因为它显示的是自mysqld服务启动之后master线程所有的loop和log刷新操作。通过对比active和idle的值，可以获知系统整体负载情况。Active的值越大，证明服务越繁忙。

图2 master thread loop

在图2中可以看到，master thread作为后台程序，一直不停的在loop，而loop过程中会选择active task 或者idle task函数执行，只有在innodb_force_recovery(对应图2的srv_force_recovery)参数设置值大于2的情况下，master thread会进入suspend状态。在srv_shutdown_state的值不等于SRV_SHUTDOWN_NONE的情况下，master thread会去执行shutdown
task。输出值srv_active，srv_idle，srv_shutdown的值分别是在函数srv_master_do_active_task，srv_master_do_idle_task，srv_master_do_shutdown_task中++。而srv_master_do_active_task的执行是由当前activity_count与old_activity_count的值决定，只要这两个值不相等，则master调用active task。在执行数据库更改操作，如插入，删除，更新，表操作的情况下，当前的activity
count的值会增加，系统调用active task。所以说，srv_active的值可以反映出系统的负载情况。值得注意的是background thread 部分的输出值是历史统计值，即mysqld服务启动之后会一直递增。

srv_master_do_active/idle/shutdown_task函数实现大体类似，区别主要在与函数返回情况不同。

srv_active

srv_idle

srv_shutdown

master thread还负责日志(redo log：重做日志)刷新log_flush_and_write记录了日志刷新的次数。在master thread中通过调用srv_sync_log_buffer_in_background函数实现日志的刷新。master thread并不是没次loop都刷新日志，而是每秒都会刷新日志，如图3所示，只有在前后刷新时间差大于等于srv_flush_log_at_timeout(对应系统参数innodb_flush_log_at_timeout)时才刷新日志。该函数调用了log_buffer_sync_in_background函数，在log_buffer_sync_in_background函数中主要的操作包括四步：①获取log_sys->mutex;②获取log的lsn；③释放log_sys->mutex；④调用log_write_up_to函数将log刷新到磁盘，如图4所示。



图3 日志刷新函数



图4 日志刷新操作

2.semphores

Semphores输出内容可以分成两段，一部分是当前的等待，这部分只是包含了在高并发环境下的全部记录(这些记录不包括sleep的)。第二部分是事件统计。相比系统等待，自旋锁的开销较小，但是它是活跃的等待，会浪费CPU资源，如果有大量的自旋等待和自旋轮转，则会浪费大量的CPU资源。

参数	说明
OS WAIT ARRAY INFO	系统等待队列信息
Reservation count	线程尝试访问os wait array的次数，大于等于线程进入os wait状态的线程数(因为尝试放入os wait array可能不成功，不成功的时候reservation count也会++)。
Signal count	线程被唤醒的次数，进入os wait的线程，在占用资源线程释放mutex的时候会通过signal唤醒等待线程。
Mutex spin wait	线程自旋等待次数，线程在获取mutex过程中如果没有获取到mutex，则首先进入自旋状态，这个时候mutex spin wait值++。
Mutex Rounds	进入spin wait的线程，通过不断循环来等待获取mutex，循环的次数称为round(理解可以参照图 4)。
Mutex Os wait	线程进入系统等待的次数，现在在获取mutex过程中，如果没有在第一时间内获取，则进入自旋，自旋达到设定的时间需求后依旧没能获取到mutex，这个时候线程进入系统等待。Os wait的值增加。
Rw-share和rw-excl：对应参数含义类似。
Spin rounds per waits mutex	每次mutex自旋等待中round的次数，值＝mutex rounds/mutex spin wait
Spin rounds per waits rw-share(读锁)	每次rw-sahre自旋等待中round的次数，值＝rw-share rounds/rw-share spin wait
Spin rounds per waits rw-excl(写锁)	每次rw-excl自旋等待中round的次数,值＝rw-excl rounds/rw-excl spin wait
注：统计信息部分给出的是自mysqld服务启动以来的累计值，进入spin wait的线程不一定会进入os wait状态，但是进入os wait状态的线程必然经历过spin wait状态。如果出现spin wait的次数与os wait次数相等或者相差不大的情况，证明绝大多数线程在spin wait状态结束后最终进入os wait状态，这种情况与innodb mutex设计初衷相违背。如果出现这样的情况，第一证明系统处于高负载，资源竞争激烈；第二，可以通过改变参数innodb_spin_wait_delay和innodb_sync_spin_loops的值来减少资源浪费。Innodb_sync_spin_loops控制的是进入spin wait状态之后循环次数，innodb_spin_wait_delay是为了延长循环时间的。统计信息给的并非实时状态，而是历史状态，如果需要观察实时状态，则必须记录两个时间点差值，这样才能充分反映当前系统状态。非高并发情况下是看不到第一部分的等待信息的，所以当你看到有第一部分信息出现的时候证明你需要关注系统状态。

Innodb中的锁包括latch和lock，在semphores部分指的都是latch，innodb自行实现了mutex，同时为了获取更好的并发性能，在mutex的基础上实现了读写锁。Mutex和写锁是完全互斥的，读锁在同一时间允许多个线程共同访问。

在数据库中latch 与lock都被称为锁，在innodb中lock针对的是事务，latch针对的是线程，latch又可以分为mutex和rw_lock，latch的目的是保证并发的线程操作临界资源的正确性。Mutex的数据结构及说明如表2所示。

表 2 mutex数据结构

变量名称	说明
lock_word	用来进行TAS操作
os_fast_mutex
waiters	是否有线程等待
list	链表
thread_id	持有mutex线程ID
file_name	mutex被锁住时的文件名
line	mutex被锁住时的行
level	latch所在的level，例如Debug模式
cfile	创建mutex对象时的文件名
cline	创建mutex时所在行
magic_n	在debug模式下检测内存是否越界

innodb为了提高读的性能，自定义了read write lock，也就是读写锁。其设计原则是：

Ø 同一时刻允许多个线程同时读取内存中的变量

Ø 同一时刻只允许一个线程更改内存中的变量

Ø 同一时刻当有线程在读取变量时不允许任何线程写存在

Ø 同一时刻当有线程在更改变量时不允许任何线程读，也不允许出自己以外的线程写（线程内可以递归占有锁）。

Ø 当有rw_lock处于线程读模式下是有线程写等待，这时候如果再有其他线程读请求锁的时，这个读请求将处于等待前面写完成。

从上面5点我们可以看出，rw_lock在被占用是会处于读状态和写状态，我们称之为S-latch(读共享)和X-latch（写独占），《MySQL技术内幕：innodb引擎》对S-latch和X_latch的描述如表 3所示。

表 3 锁类型兼容矩阵

	x-latch	s-latch
x-latch	conflict	conflict
s-latch	conflict	compatible

操作系统本身有提供latch，但是Innodb基于自旋锁重写了mutex，其主要原因是：因为传统的mutex在获取不到的时候，线程会直接进入wait队列，等待被唤醒，cpu在线程进入wait队列的时候切换上下文环境。常见操作系统线程上下文切换耗时大约25um，再加上lock与unlock的时间开销。Innodb将spin的时间设置为20um，当前奔腾平台一个操作持有mutex或者rw-lock的时间一般在1-20um，自旋20um在绝大多数情况下能获取到mutex，相比进入os wait，spin的时间20um不算多。表 4给出了mutex的获取流程。通过TAS(test_and_set)指令检测mutex是否被释放。表中参数sync_spin_rounds对应innodb参数innodb_sync_spin_rounds，主要是为了避免无限自旋而设计的。在线程自旋无法获取mutex的时候，线程进入os wait队列，并将mutex数据结构中waiters值设置为1，为的是在持有mutex线程释放mutex时，能去os wait队列中唤醒该线程。

此外，Innodb基于自己的mutex实现基础上实现了rw-lock，读写锁包括x-latch与s-latch。S-latch表示对临界资源上共享锁，允许多个线程访问资源，x-latch表示对临界资源上排他锁，只运行一个线程访问该资源。信号量获取流程如图 21所示。

表 4 获取mutex流程

if (test_and_set(mutex->lock_word)==0){
get mutex;
return;}
loop:
while(mutex->lock_word!=0&& i<sync_spin_rounds){spin;i++;}
if (test_and_set(mutex->lock_word)==0){
get mutex; return;}
reserve a cell from wait array;
mutex->waiters=1;
for(i=0;i<4;i++){
if(test_and_set(mutex->lock_word)==0){
get mutex; free cell; return;}
wait event;
goto loop;}

图5 mutex获取流程

Innodb提供了两个参数可以对mutex的spin进行调整，参数如图 6所示。Innodb_sync_spin_loops设定的是线程在获取mutex过程中，如果没在第一时间获取到mutex，线程首先进入自旋，自旋的loops达到该值之后仍未获取到mutex，则释放占用的资源，进入array cell，状态os wait，等待被唤醒。Innodb_sync_wait_delay设定了在spin的过程中，依赖区间[0,innodb_spin_wait_delay]生成随机数，产生延迟。对于稳定运行系统，可以根据系统获取mutex平均等待时间，合理设置这两个参数值，例如：semphores部分内容显示，spin_wait和os wait的值基本相近，那就说明该系统spin效果不明显，innodb之所以采用spin的原因就是为了减少线程进入os wait以及被唤醒的开销，如果系统结果显示，spin wait之后最终还是要去到os wait，那就证明spin设置较大值是一种浪费。



图6 自旋相关参数