接下来是显示 Innodb 当前活跃的事务：

1.------------
2.TRANSACTIONS
3.------------
4.Trx id counter 0 80157601
5.Purge done for trx's n:o <0 80154573 undo n:o <0 0
6.History list length 6
7.Total number of lock structs in row lock hash table 0
8.LIST OF TRANSACTIONS FOR EACH SESSION:
9.---TRANSACTION 0 0, not started, process no 3396, OS thread id 1152440672
10.MySQL thread id 8080, query id 728900 localhost root
11.show innodb status
12.---TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442
13.mysql tables in use 1, locked 0
14.MySQL thread id 8079, query id 728899 localhost root Sending data
15.select sql_calc_found_rows  * from b limit 5
16.Trx read view will not see trx with id>= 0 80157601, sees <0 80157597
17.---TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166
18.mysql tables in use 1, locked 0
19.MySQL thread id 8078, query id 728898 localhost root Sending data
20.select sql_calc_found_rows  * from b limit 5
21.Trx read view will not see trx with id>= 0 80157600, sees <0 80157596
22.---TRANSACTION 0 80157598, ACTIVE 7 sec, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114
23.mysql tables in use 1, locked 0
24.MySQL thread id 8077, query id 728897 localhost root Sending data
25.select sql_calc_found_rows  * from b limit 5
26.Trx read view will not see trx with id>= 0 80157599, sees <0 80157595
27.---TRANSACTION 0 80157597, ACTIVE 7 sec, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400
28.mysql tables in use 1, locked 0
29.MySQL thread id 8076, query id 728896 localhost root Sending data
30.select sql_calc_found_rows  * from b limit 5
31.Trx read view will not see trx with id>= 0 80157598, sees <0 80157594

如果当前连接不是很多，则会显示全部事务列表；如果有大量连接，则 Innodb 只会显示他们的数量，减少输出的列表信息，使得输出结果不会太多。

事务ID是当前事务的标识，事务的id每次都会增加。Purge done for trx's n:o 是指净化(purge)线程已经完成的事务数。Innodb仅清除那些被当前事务认为不再需要的旧版本数据。那些未提交的旧事务可能会阻塞净化线程并且消耗资源。通过查看2次清除事务数之差，就可以知道是否发生了这种情况。少数情况下，净化线程可能难以跟上更新的速度，2次查看值之差可能会越来越大；那么，innodb_max_purge_lag 就派得上用场了。 "undo n:o" 显示了净化线程当前正在处理的回滚日志号，如果当前不处于活跃状态，则它的值是 0。

History list length 6 是指在回滚空间中的未清除事务数。随着事务的提交，它的值会增加；随着清除线程的运行，它的值会减小。

Total number of lock structs in row lock hash table 是指事务分配过的行锁结构总数。它和曾经被锁住过的行总数不一定相等，通常是一个锁结构对应多行记录。

MySQL中，每个连接如果没有活动的事务，则它的状态是 not started，如果有活动的事务，则是 ACTIVE。注意，尽管事务是活动的，但是其连接的状态却可能是 "睡眠(sleep)" - 如果是在一个有多条语句的事务里的话。Innodb 会同时显示系统的线程号以及进程号，这有助于利用gdb来调试或者其他类似用途。另外，事务的状态也会根据当前实际状态来显示，例如 "读取记录(fetching rows)"，em>"更新(updating)"等等。"Thread declared inside InnoDB 400" 的意思是 Innodb 内核正在运行该线程，并且还需要400个票。Innodb 会根据 innodb_thread_concurrency 的值来限制同时并发的线程数不超过它。如果线程当前不在 Innodb 的内核中运行，则它的状态可能是"waiting in InnoDB queue" 或 "sleeping before joining InnoDB queue"。后面这个状态有点意思 - Innodb 为了避免有太多的线程同时抢着要进入运行队列，那么就会尝试让这些线程进入等待状态(如果没有足够的空闲插槽(slot)的话)。这就可能会导致 Innodb 内核中当前活跃的线程数可能比 innodb_thread_concurrency 的值还小。某种负载环境下，这可能有助于减小线程进入队列的时间。可以通过调整innodb_thread_sleep_delay 来实现，它的单位是微妙。

mysql tables in use 1, locked 0 是指事务中已经用过的数据表个数(已经访问过了的)，以及被锁的个数。Innodb 一般情况不会锁表，因此锁表数一般是0，除非是 ALTER TABLE 或者其他类似 LOCK TABLES 的语句。

除了Innodb相关的特定信息外，一些基本信息可以通过 来查看，例如正在执行什么语句，查询ID号，查询状态等。

下面这部分显示的是跟IO相关的具体信息：

1.--------
2.FILE I/O
3.--------
4.I/O thread 0 state: waiting for i/o request (insert buffer thread)
5.I/O thread 1 state: waiting for i/o request (log thread)
6.I/O thread 2 state: waiting for i/o request (read thread)
7.I/O thread 3 state: waiting for i/o request (write thread)
8.Pending normal aio reads: 0, aio writes: 0,
9. ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
10.Pending flushes (fsync) log: 0; buffer pool: 0
11.17909940 OS file reads, 22088963 OS file writes, 1743764 OS fsyncs
12.0.20 reads/s, 16384 avg bytes/read, 5.00 writes/s, 0.80 fsyncs/s

本部分显示了IO助手线程状态 - 插入缓冲线程，日志线程，读、写线程。它们分别对应插入缓冲合并，异步日志刷新，预读以及刷新脏数据。源自查询的正常读取是由正在运行的查询执行的。在Unix/Linux平台下，总能看见4个线程，在Windows上可以通过innodb_file_io_threads 来调整。每个线程准备好之后都能看到其状态：waiting for i/o request 或者正在执行特定的操作。

每个线程都会显示正在进行的操作数量 - 同时正要执行或者正在执行的操作数量。另外，正在执行的 fsync 操作数量也会显示出来。有写数据时，Innodb需要确保数据最终被写到磁盘上，只是把它们放在系统缓存里是不够的。通常是调用 fsync() 来完成的。如果它的值一直很高，那意味这Innodb可能是处于IO负载较高状态。注意，由线程执行请求引发的IO请求是不计算在内的，因此尽管系统的IO负载较高，但是它们的值却可能为 0。

接下来显示的是IO操作的平均统计值，它们对于图形显示或者监控很有用。
"16384 avg bytes/read" 是读请求的平均值。随机IO的话，每个页的大小是16K，全表扫描或索引扫描时的预读会导致这个值明显的增加。因此，它体现了预读的效率。

1.-------------------------------------
2.INSERT BUFFER AND ADAPTIVE HASH INDEX
3.-------------------------------------
4.Ibuf for space 0: size 1, free list len 887, seg size 889, is not empty
5.Ibuf for space 0: size 1, free list len 887, seg size 889,
6.2431891 inserts, 2672643 merged recs, 1059730 merges
7.Hash table size 8850487, used cells 2381348, node heap has 4091 buffer(s)
8.2208.17 hash searches/s, 175.05 non-hash searches/s

本部分显示了插入缓冲以及自适应哈希索引的状态。第一行显示了插入缓冲的状态 - 段的大小以及空闲列表，以及缓冲中有多少记录。接下来显示了缓冲中已经完成了多少次插入，有多少记录已经合并，有多少次合并已经完成。合并次数除以插入次数得到的比率可以反映出插入缓冲的效率如何。

Innodb采用哈希索引建立内存页索引形成自适应哈希索引而不是采 B-tree 索引，得以加速行记录到内存页的检索。这里显示了哈希表的大小，以及自适应哈希索引使用了多少单元和缓冲。可以通过计算利用哈希索引检索的次数以及没利用它检索的次数来了解哈希索引的效率。

当前对自适应哈希索引基本没有什么办法可以调整它，主要还是用于查看。

1.---
2.LOG
3.---
4.Log sequence number 84 3000620880
5.Log flushed up to   84 3000611265
6.Last checkpoint at  84 2939889199
7.0 pending log writes, 0 pending chkp writes
8.14073669 log i/o's done, 10.90 log i/o's/second

接下来显示的是Innodb的日志子系统相关信息。可以看到当前的日志序列号 - 相当于Innodb自从表空间开始创建直到现在已经写入日志文件的总字节数。还可以看到日志已经刷新到哪个点，同样也可以根据最后检查点计算出还有多少日志没有刷新到文件中去。Innodb采用模糊检查点，因此这行显示的是已经从缓冲池中刷新到文件的日志序列号。由于更高的日志序列号可能不会被立刻刷新到日志文件中去，因此日志序列号不能被覆盖掉。通过监控刷新到哪个日志的日志序列，可以判定 innodb_log_buffer_size的设置是否合理，如果看到超过 30% 的日志还没有刷新到日志文件中，则需要考虑增加它的值了。

另外，还能看到日志写入以及检查点的数目。根据日志 I/O 操作的数目可以区分开表空间相关的IO请求和日志IO请求数量，进而可以确定到底需要几个日志文件。注意，innodb_flush_log_at_trx_commit 的值可以影响到日志写操作的代价高或低。如果 innodb_flush_logs_at_trx_commit=2，则日志是写到系统缓存，然后再顺序写到日志文件中，因此相对会快很多。