show engine innodb status解读

参考 https://www.cnblogs.com/xiaoboluo768/p/5171425.html

show engine innodb status 是mysql提供的一个用于查看innodb引擎时间信息的工具，就目前来说有两处比较常用的地方一、死锁分析二、innodb内存使用情况

1、Per second averages calculated from the last 7 seconds

第四行显示的是计算出这一平均值的时间间隔，即自上次输出以来的时间，或者是距上次内部复位的时长

2、BACKGROUND THREAD

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

srv_master_thread loops: 1613076 srv_active, 0 srv_shutdown, 17217516 srv_idle

srv_master_thread log flush and writes: 18829661

Master thread是一个非常核心的后台线程，主要负责缓冲池中的数据异步刷新到磁盘，保证数据的一致性。Master thread具有最高的线程优先级别，其内部由多个循环(loop)组成:主循环，后台循环，刷新循环，暂停循环。

参数	说明
Srv_master_thread loops	Master线程的循环次数，master线程在每次loop过程中都会sleep，sleep的时间为1秒。而在每次loop的过程中会选择active、shutdown、idle中一种状态执行。Master线程在不停循环，所以其值是随时间递增的。
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的值越大，证明服务越繁忙。

3、SEMAPHORES

----------

SEMAPHORES

----------

OS WAIT ARRAY INFO: reservation count 1250821

OS WAIT ARRAY INFO: signal count 2665140

RW-shared spins 0, rounds 2438165, OS waits 1009620

RW-excl spins 0, rounds 2745381, OS waits 128849

RW-sx spins 4054, rounds 85170, OS waits 1849

Spin rounds per wait: 2438165.00 RW-shared, 2745381.00 RW-excl, 21.01 RW-sx

reservation count：线程尝试访问os wait array的次数，大于等于线程进入os wait状态的线程数(因为尝试放入os wait array可能不成功，不成功的时候reservation count也会++)

Signal count：线程被唤醒的次数，进入os wait的线程，在占用资源线程释放mutex的时候会通过signal唤醒等待线程。

Mutex spin waits 是线程无法获取锁，而进入的spin wait

rounds 是spin wait进行轮询检查Mutextes的次数

OS waits 是线程放弃spin-wait进入挂起状态

buf0buf.c实际上表示服务器有buffer pool争用的情况。

--Thread 140653057947392 has waited at btr0pcur.c line 437 for 0.00 seconds the semaphore:

S-lock on RW-latch at 0x7ff536c7d3c0 created in file buf0buf.c line 916

a writer (thread id 140653057947392) has reserved it in mode exclusive

number of readers 0, waiters flag 1, lock_word: 0

Last time read locked in file row0sel.c line 3097

Last time write locked in file /usr/local/src/soft/mysql-5.5.24/storage/innobase/buf/buf0buf.c line 3151

--Thread 140653677291264 has waited at btr0pcur.c line 437 for 0.00 seconds the semaphore:

S-lock on RW-latch at 0x7ff53945b240 created in file buf0buf.c line 916

a writer (thread id 140653677291264) has reserved it in mode exclusive

number of readers 0, waiters flag 1, lock_word: 0

Last time read locked in file row0sel.c line 3097

Last time write locked in file /usr/local/src/soft/mysql-5.5.24/storage/innobase/buf/buf0buf.c line 3151

这部分显示的是当前正在等待互斥量的innodb线程，在这里可以看到有两个线程正在等待，每一个都是以--Thread <数字> has waited...开始，这一段内容在正常情况下应该是空的（即查看的时候没有这部分内容），除非服务器运行着高并发的工作负载，促使innodb采取让操作系统等待的措施，除非你对innodb源码熟悉，否则这里看到的最有用的信息就是发生线程等待的代码文件名 /usr/local/src/soft/mysql-5.5.24/storage/innobase/buf/buf0buf.c line 3151

4、LATEST DETECTED DEADLOCK

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

LATEST DETECTED DEADLOCK

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

2019-12-26 17:21:01 0x7f4750537700

*** (1) TRANSACTION:

TRANSACTION 25908, ACTIVE 14 sec starting index read

mysql tables in use 1, locked 1

LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1

MySQL thread id 6, OS thread handle 139944266782464, query id 166 localhost root updating

update emp set sal = sal + 1 where id = 3

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 221 page no 3 n bits 80 index PRIMARY of table `testdb`.`emp` trx id 25908 lock_mode X locks rec but not gap waiting

Record lock, heap no 4 PHYSICAL RECORD: n_fields 6; compact format; info bits 0

0: len 4; hex 80000003; asc ;;

1: len 6; hex 000000006532; asc e2;;

2: len 7; hex 2b000001661601; asc + f ;;

3: len 3; hex 777a78; asc wzx;;

4: len 4; hex 8000051e; asc ;;

5: len 4; hex 80000001; asc ;;

5、TRANSACTIONS

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

TRANSACTIONS

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

Trx id counter 25904

Purge done for trx's n:o < 25904 undo n:o < 0 state: running but idle

History list length 6 #历史记录的长度

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 421419673434848, not started

0 lock struct(s), heap size 1136, 0 row lock(s)

---TRANSACTION 421419673433936, not started

0 lock struct(s), heap size 1136, 0 row lock(s)

---TRANSACTION 25899, ACTIVE 742 sec

2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1

MySQL thread id 6, OS thread handle 139944266782464, query id 126 localhost root

purge… :清楚旧事务的事务ID

6、FILE I/O

I/O thread 0 state: waiting for i/o request (insert buffer thread)

I/O thread 1 state: waiting for i/o request (log thread)

I/O thread 2 state: waiting for i/o request (read thread)

I/O thread 3 state: waiting for i/o request (read thread)

I/O thread 4 state: waiting for i/o request (read thread)

I/O thread 5 state: waiting for i/o request (read thread)

I/O thread 6 state: waiting for i/o request (write thread)

I/O thread 7 state: waiting for i/o request (write thread)

I/O thread 8 state: waiting for i/o request (write thread)

I/O thread 9 state: waiting for i/o request (write thread)

Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] , #读线程和写线程挂起操作的数目等，aio的意思是异步I/O

ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0 #insert buffer thread挂起的fsync()操作数目等

Pending flushes (fsync) log: 0; buffer pool: 0 #log thread挂起的fsync()操作数目等

260194744 OS file reads, 1609166627 OS file writes, 644981248 OS fsyncs

0.00 reads/s, 0 avg bytes/read, 1.36 writes/s, 1.36 fsyncs/s #这行显示了读，写和fsync()调用执行的数目，在你的机器环境负载下这些绝对值可能会有所不同，因此更重要的是监控它们过去一段时间内是如何改变的。

注：三行挂起读写线程、缓冲池线程、日志线程的统计信息的值是检测I/O受限的应用的一个好方法，如果这些I/O大部分有挂起操作，那么负载可能I/O受限。在linux系统下使用参数：innodb_read_io_threads和innodb_write_io_threads两个变量来配置读写线程的数量，默认为各4个线程。

insert buffer thread：负责插入缓冲合并，如：记录被从插入缓冲合并到表空间中

log thread：负责异步刷事务日志

read thread：执行预读操作以尝试预先读取innodb预感需要的数据

write thread：刷新脏页缓冲

7、INSERT BUFFER AND ADAPTIVE HASH INDEX

Ibuf: size 12, free list len 27559, seg size 27572, 18074934 merges #这行显示了关于size（size 12代表了已经合并记录页的数量）、free list（代表了插入缓冲中空闲列表长度）和seg size大小（seg size 27572显示了当前insert buffer的长度，大小为27572*16K=440M左右）的信息。18074934 merges代表合并插入的次数

merged operations: #这个标签下的一行信息insert，delete mark，delete分别表示merge操作合并了多少个insert buffer，delete buffer，purge buffer

insert 81340470, delete mark 8893610, delete 818579

discarded operations: #这个标签下的一行信息表示当change buffer发生merge时表已经被删除了，就不需要再将记录合并到辅助索引中了

insert 0, delete mark 0, delete 0

Hash table size 87709057, node heap has 10228 buffer(s) #这行显示了自使用哈希索引的状态，其中，Hash table size 87709057表示AHI的大小，node heap has 10228 buffer(s)表示AHI的使用情况

1741.05 hash searches/s, 539.48 non-hash searches/s #这行显示了在头部第1部分提及的时间内Innodb每秒完成了多少哈希索引操作，1741.05 hash searches/s表示每秒使用AHI搜索的情况，539.48 non-hash searches/s表示每秒没有使用AHI搜索的情况(因为哈希索引只能用于等值查询，而范围查询，模糊查询是不能使用哈希索引的。)，通过hash searches: non-hash searches的比例大概可以了解使用哈希索引后的效率，哈希索引查找与非哈希索引查找的比例仅供参考，自适应哈希索引无法配置，但是可以通过innodb_adaptive_hash_index=ON|OFF参数来选择是否需要这个特性。

注：

innodb从1.0.x开始引入change buffer，可以视为insert buffer的升级，从这个版本开始，innodb可以对DML操作(insert,delete,update)都进行缓冲，他们分别是insert buffer,delete buffer,purge buffer，当然和之前insert buffer一样，change buffer适用对象仍然是非唯一索引的辅助索引，因为没有update buffer，所以对一条记录进行update的操作可以分为两个过程：

A：将记录标记为删除

B：真正将记录删除

因此，delete buffer对应update 操作的第一个过程，即将记录标记为删除，purge buffer对应update的第二个过程，即将记录真正地删除

8、LOG

LOG

---

Log sequence number 1351392990515 #这行显示了当前最新数据产生的日志序列号

Log flushed up to 1351392989504 #这行显示了日志已经刷新到哪个位置了（已经落盘到事务日志中的日志序列号）

Last checkpoint at 1351373900020 #这行显示了上一次检查点的位置（一个检查点表示一个数据和日志文件都处于一致状态的时刻，并且能用于恢复数据），如果上一次检查点落后与上一行太多，并且差异接近于事务日志文件的大小，Innodb会触发“疯狂刷”，这对性能而言非常糟糕。

0 pending log writes, 0 pending chkp writes #这行显示了当前挂起的日志读写操作，可以将这行的值与第7部分FILE I/O对应的值做比较，以了解你的I/O有多少是由于日志系统引起的。

286879989 log i/o's done, 15.92 log i/o's/second #这行显示了日志操作的统计和每秒日志I/O数，可以将这行的值与第7部分FILE I/O对应的值做比较，以了解你的I/O有多少是由于日志系统引起的

9、BUFFER POOL AND MEMORY

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

Total large memory allocated 274857984 # 为innodb 分配的总内存数(byte)

Dictionary memory allocated 116177 #为innodb数据字典分配的内存数(byte)

Buffer pool size 16384 #innodb_buffer_pool的大小(page)

Free buffers 16004 #innodb_buffer_pool lru列表中的空闲页面数量

Database pages 380 #innodb_buffer_pool lru列表中的非空闲页面数

Old database pages 0 #innodb_buffer_pool old子列表的页面数量

Modified db pages 0 #innodb_buffer_pool 中脏页的数量

Pending reads 0 #挂起读的数量

Pending writes: LRU 0, flush list 0, single page 0 #

Pages made young 0, not young 0

0.00 youngs/s, 0.00 non-youngs/s

Pages read 345, created 35, written 37

0.00 reads/s, 0.00 creates/s, 0.00 writes/s

No buffer pool page gets since the last printout

Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s

LRU len: 380, unzip_LRU len: 0

I/O sum[0]:cur[0], unzip sum[0]:cur[0]

10、ROW OPERATIONS

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

0 queries inside InnoDB, 0 queries in queue #这行显示了innodb内核内有多少个线程，队列中有多少个线程，队列中的查询是innodb为限制并发执行的线程数量而不运行进入内核的线程。查询在进入队列之前会休眠等待。

5 read views open inside InnoDB #这行显示了有多少打开的innodb读视图，读视图是包含事务开始点的数据库内容的MVCC快照，你可以看看某特定事务在第6部分TRANSACTIONS是否有读视图

Main thread process no. 4368, id 140653691242240, state: sleeping #这行显示了内核的主线程状态

Number of rows inserted 3429012215, updated 153529675, deleted 112310240, read 3739562987410 #这行显示了多少行被插入，更新和删除，读取

428.52 inserts/s, 7.21 updates/s, 0.46 deletes/s, 1047933.92 reads/s #这行显示了对应上面一行的每秒平均值，如果想查看innodb有多少工作量在进行，那么这两行是很好的参考值