InnoDB信息说明
InnoDB是MySQL数据库发展至今一款至关重要的数据库存储引擎，其不仅支持事务特性，并且具有丰富的统计信息，便于数据库管理人员了解最近InnoDB存储引擎的运行状态。
早期版本的InnoDB存储引擎通过在内部新建一张名为innodb_monitor的表进行实现，InnoDB内部检测到该表后，会定时输出InnoDB引擎相关统计信息。而现在的InnoDB存储引擎通过命令show engine innodb status实现对InnoDB存储引擎统计信息的查看，在MySQL客户端执行show engine innodb status\G，获取到的结果可能如下：
=====================================
140708 21:35:01 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 54 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 129 1_second, 128 sleeps, 8 10_second, 76 background, 76 flush
srv_master_thread log flush and writes: 129
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 53606, signal count 55906
Mutex spin waits 525951, rounds 2435436, OS waits 40130
RW-shared spins 36905, rounds 444653, OS waits 9660
RW-excl spins 5298, rounds 156489, OS waits 2307
Spin rounds per wait: 4.63 mutex, 12.05 RW-shared, 29.54 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 19FFF
Purge done for trx's n:o < 13696 undo n:o < 0
History list length 15274
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 19F65, not started
mysql tables in use 1, locked 0
MySQL thread id 52, OS thread handle 0x7f8bfd1b9700, query id 1040279 localhost root
SELECT c FROM sbtest1 WHERE id=199077
………………... any other TRANSACTIONS ……………………..
--------
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)
………………. other three read threads …………….….
I/O thread 6 state: waiting for completed aio requests (write thread)
………………. other three write threads …………….….
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 1; buffer pool: 0; flash cache 0
296 OS file reads, 47547 OS file writes, 40960 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 755.62 writes/s, 750.19 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 21249841, node heap has 294 buffer(s)
17860.30 hash searches/s, 13956.39 non-hash searches/s
---
LOG
---
Log sequence number 184703155
Log flushed up to 184699426
Last checkpoint at 109334220
1 pending log writes, 0 pending chkp writes
40703 log i/o's done, 749.84 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 10994319360; in additional pool allocated 0
Dictionary memory allocated 43910
Buffer pool size 655359
Free buffers 646841
Database pages 8224
Old database pages 3015
Modified db pages 5270
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 1, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 149, created 8075, written 6557
0.00 reads/s, 38.13 creates/s, 5.52 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 8224, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
Async Flush: 0, Sync Flush: 0, LRU List Flush: 0, Flush List Flush: 6557
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
61 read views open inside InnoDB
Main thread process no. 30423, id 140238424880896, state: sleeping
Number of rows inserted 451965, updated 103933, deleted 51957, read 21009001
962.26 inserts/s, 1924.65 updates/s, 962.15 deletes/s, 381640.41 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
二、 统计信息说明
根据上面的显示，可以把InnoDB存储引擎的统计信息分为：
1. 基础信息
2. 后台线程(background thread)
3. 信号量(semaphores)
4. 事务(transactions)
5. I/O
6. insert buffer & adaptive hash
7. log
8. buffer pool & memory
9. row operations
下面结合上节中显示的信息分别对以上分类进行说明。
基础信息
Per second averages calculated from the last 54 seconds
InnoDB内部统计的信息都是一段时间内的平均值，默认情况下为60s一个时间间隔计算，上述显示的54s是执行show engine innodb status命令距上次统计结束为54s，下面显示的信息为54s内的平均值，一般认为，该值在比较大时才有意义，因为当该值比较小时，偶然的波动会造成统计信息变化很大，不能很好地反应InnoDB存储引擎内部实际情况。
background thread
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 129 1_second, 128 sleeps, 8 10_second, 76 background, 76 flush
srv_master_thread log flush and writes: 129
MySQL内部后台有个线程负责数据的刷盘和undo的清理(不使用独立的purge线程)工作，后台线程是一个死循环，根据InnoDB存储引擎的繁忙程度执行数据刷盘操作，主要操作如下图：
从background thread信息中，可以看出1s的循环有129次，10s的循环有8次，128次sleep和76次进入background模式，进行了76次数据刷盘和129次日志刷盘，整个background thread信息显示，InnoDB内部处于相对空闲状态。
semaphores
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 53606, signal count 55906
Mutex spin waits 525951, rounds 2435436, OS waits 40130
RW-shared spins 36905, rounds 444653, OS waits 9660
RW-excl spins 5298, rounds 156489, OS waits 2307
Spin rounds per wait: 4.63 mutex, 12.05 RW-shared, 29.54 RW-excl
信号量段显示了InnoDB存储引擎内部锁信息，在大并发量请求时，InnoDB不可避免存在资源竞争，这个时候，部分事务需要通过锁等待，等待相关事务释放资源后才能继续执行，上面显示的饿信息就是InnoDB内部锁等待信息。除了上面部分信息外，如果InnoDB存储引擎存在死锁状态，还会在以上信息下面增加相应的的死锁信息。
transactions
------------
TRANSACTIONS
------------
Trx id counter 19FFF
Purge done for trx's n:o < 13696 undo n:o < 0
History list length 15274
事务段信息显示当前InnoDB内部正在执行的事务，因为InnoDB存储引擎支持事务并发执行，所以InnoDB内部同时存在许多事务。
事务id在InnoDB内部是递增的，从当前事务信息看，下一个事务id为0x19FFF，而当前purge到的undo日志号no为13695，当前等待purge操作的事务有15274个，单从这些信息上就可以看出，当前InnoDB内部处于繁忙状态，等待pruge的事务数在不断增加。
上面一部分可以看做是事务的总结信息，而LIST OF TRANSACTIONS FOR EACH SESSION:后面显示的是当前InnoDB内部每个事务的具体状态：
---TRANSACTION 19F65, not started
mysql tables in use 1, locked 0
MySQL thread id 52, OS thread handle 0x7f8bfd1b9700, query id 1040279 localhost root
SELECT c FROM sbtest1 WHERE id=199077
上述显示了当前InnoDB内部1个事务的信息，not started说明该事务处于非活动状态，如果是活动状态则为active，mysql tables in use说明当前事务操作的表数，locked表示表被锁的个数(innodb内部支持行锁，所以一般表锁使用比较少，只有在如alter table等操作是才会锁表)，mysql thread id为当前连接分配的id，os thread handle为连接线程的句柄，query id为当前查询的id，后面显示了具体的查询SQL。
I/O
--------
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)
………………. other three read threads …………….….
I/O thread 6 state: waiting for completed aio requests (write thread)
………………. other three write threads …………….….
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 1; buffer pool: 0; flash cache 0
296 OS file reads, 47547 OS file writes, 40960 OS fsyncs
reads/s, 0 avg bytes/read, 755.62 writes/s, 750.19 fsyncs/s
I/O段显示当前InnoDB引擎内部I/O使用情况，InnoDB内部采用异步I/O的模式进行数据的读写操作，默认情况下有1个insert buffer线程，1个日志线程，4个读数据线程和4个写数据线程。
线程信息后面部分为I/O统计信息，总共进行了296次读取，47547次写入，fsync为40960次，平均读数据为0，写输入为755.62次/s， fsyncs为750.19次/s，从以上信息分析，该InnoDB存储引擎内部事务基本上都是写入事务，I/O基本已经达到性能瓶颈。
insert buffer & adaptive hash
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
上面部分显示插入缓冲信息，从MySQL 5.5开始，insert buffer不止统计insert信息还包括delete和update信息，被称之为change buffer(delete mark为update的信息，InnoDB内部update通过把记录的delete flag设置成true实现)。
单从上面的信息来看，change buffer没有涉及到需要合并的insert/update/delete操作，insert buffer功能没能得到利用。
Hash table size 21249841, node heap has 294 buffer(s)
17860.30 hash searches/s, 13956.39 non-hash searches/s
InnoDB内部对已某张页查询达到一定数量后，内部会为该页采用哈希方式建立索引，InnoDB认为，当某张页在一段时间被频繁使用时，那么在后面被用到的概率也将非常高，所以为该页建立哈希索引能加速该页的查找。hash table size显示了内部自适应哈希表的大小，hash search和non-hash search分别显示了InnoDB内部查找时使用自适应哈希和普通索引查找每秒的次数，单从上述信息看来自适应哈希查找占到了55%左右，自适应哈希效果明显。
log
---
LOG
---
Log sequence number 184703155
Log flushed up to 184699426
Last checkpoint at 109334220
1 pending log writes, 0 pending chkp writes
40703 log i/o's done, 749.84 log i/o's/second
InnoDB log信息显示了当前内部重做日志(redo log)的写入情况，InnoDB内部通过LSN来实现redo log和事务的对应，log sequence number说明当前系统内部事务执行LSN为184703155，而log flushed up to表示redo log已经保存到磁盘的LSN为184699426，而last checkpoint at表示最近数据和redo log都保存到磁盘的LSN为109334220。
通过上面的信息可以得知：如果这个时候发生某种意外导致MySQL意外宕机，LSN > 184699426的事务可能会被丢失，而LSN在109334220和184699426中间的事务需要通过redo log恢复。LSN < 109334220的数据，因为已经保存到磁盘了，所以不会因为宕机而丢失。
buffer pool & memory
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 10994319360; in additional pool allocated 0
Dictionary memory allocated 43910
Buffer pool size 655359
Free buffers 646841
Database pages 8224
Old database pages 3015
Modified db pages 5270
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 1, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 149, created 8075, written 6557
0.00 reads/s, 38.13 creates/s, 5.52 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 8224, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
Async Flush: 0, Sync Flush: 0, LRU List Flush: 0, Flush List Flush: 6557
InnoDB内部采用buffer pool的形式缓存数据，对于InnoDB存储引擎来说，buffer pool越大，内存中缓存的数据也就越多，系统的性能就越好。上述信息显示，InnoDB占用内存大约10G，
buffer的大小大约为655359(单位16K，下同)，而空闲大约为646841，被使用的页为8224 + 3015，其中脏页为8224, 3015为非脏页。
从上述信息显示，InnoDB内存过大，数据全部落在内存中。
Buffer pool hit rate 1000 / 1000内存命中率100%，等待flush的页为6557
row operations
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
61 read views open inside InnoDB
Main thread process no. 30423, id 140238424880896, state: sleeping
Number of rows inserted 451965, updated 103933, deleted 51957, read 21009001
962.26 inserts/s, 1924.65 updates/s, 962.15 deletes/s, 381640.41 reads/s
row operations显示了InnoDB存储引擎内部记录操作信息，打开了61个read views，后面显示了主线程信息和状态，最后显示了自启动以来，所有的insert/update/delete/read数量和每秒的平均值。
InnoDB信息说明的更多相关文章
- 14.6.1 Creating InnoDB Tables 创建InnoDB 表:
14.6.1 Creating InnoDB Tables 创建InnoDB 表: 创建一个InnoDB 表,使用CREATE TABLE 语句,你不需要指定 ENGINE=InnoDB子句 如果In ...
- InnoDB Monitors | SHOW ENGINE INNODB STATUS
参考 <mysql 5.7手册>,15.17章节 InnoDB监视器提供有关InnoDB内部状态的信息. 这些信息对于性能调优非常有用.其实所谓的监视器,就是 show engine in ...
- python之路十二
本节内容 数据库介绍 mysql 数据库安装使用 mysql管理 mysql 数据类型 常用mysql命令 创建数据库 外键 增删改查表 权限 事务 索引 python 操作mysql ORM sql ...
- 十二天 mysql操作
本节内容 数据库介绍 mysql 数据库安装使用 mysql管理 mysql 数据类型 常用mysql命令 创建数据库 外键 增删改查表 权限 事务 索引 python 操作mysql ORM sql ...
- Python_Day12_python mysql and ORM and redis
本节内容 数据库介绍 mysql 数据库安装使用 mysql管理 mysql 数据类型 常用mysql命令事务 创建数据库 外键 增删改查表 权限 事务 索引 python 操作mysql 1. 数 ...
- Python自动化 【第十二篇】：Python进阶-MySQL和ORM
本节内容 数据库介绍 mysql 数据库安装使用 mysql管理 mysql 数据类型 常用mysql命令 创建数据库 外键 增删改查表 权限 事务 索引 python 操作mysql ORM sql ...
- python 之路，Day11（上） - python mysql and ORM
python 之路,Day11 - python mysql and ORM 本节内容 数据库介绍 mysql 数据库安装使用 mysql管理 mysql 数据类型 常用mysql命令 创建数据库 ...
- Day11 - Mysql and ORM
python 之路,Day11 - python mysql and ORM 本节内容 数据库介绍 mysql 数据库安装使用 mysql管理 mysql 数据类型 常用mysql命令 创建数据库 ...
- linux系统安装mysql
所有平台的Mysql下载地址为: MySQL 下载. 挑选你需要的 MySQL Community Server版本及对应的平台. 接下来我们在 Centos 系统下使用 yum 命令安装 MySql ...
随机推荐
- zookeeper 配置文件注释
tickTime=2000 initLimit=5 syncLimit=2 dataDir=/opt/shencl/zookeeper/data/data0 dataLogDir=/opt/shenc ...
- centos5.5源更新方法（网易163源 很快的源）
http://blog.chinaunix.net/uid-24993824-id-189965.html 1.首先,打开终端,获取root权限 2.关闭fastestmirror插件 ...
- Unity3D之Mesh（二）为三角形添加纹理
一.直接開始上步驟 首先繪製一個三角形 創建一個材質,以便後續使用: 1)材質使用的貼圖 2)上代碼 using UnityEngine; using System.Collections; /* = ...
- npm-install once
Once 是我最习惯的模块,它展示了几乎所有的我书写的通过issac Schlueter创建的应用. 原理很简单,Once使用各类一个函数且返回了一个函数,你可以调用这个函数,但是只能调用一次.如果你 ...
- JQuery表单验证插件EasyValidator
本插件的宗旨是:用户无需写一行JS验证代码,只需在要验证的表单中加入相应的验证属性即可,让验证功能易维护,可扩展,更容易上手. DEMO中已经包含了常用的正则表达式,可以直接复用,为了考虑扩展性,所以 ...
- 我对java的理解（二）——反射是小偷的万能钥匙
在我们生活中,车上或者路上有时候会遇到一种很讨厌的人——“小偷”,趁我们不注意或者疏忽的时候拿走属于我们的东西.更有甚者,趁我们不在家的时候,手持一把万能钥匙,打开我们的房门,悠闲的查看房间的布置,翻 ...
- hihocoder-1284 机会渺茫(水题)
机会渺茫 时间限制:5000ms 单点时限:1000ms 内存限制:256MB 描述 小Hi最近在追求一名学数学的女生小Z.小Z其实是想拒绝他的,但是找不到好的说辞,于是提出了这样的要求:对于给定的两 ...
- bzoj1000~1025
以后还是这样 25道题一起发 看着爽 noip失利之后发粪涂墙 刷了一波bzoj 题解: bzoj1000 A+B问题 这题不同的人有不同的写法,我写了个线段树套Treap,应该还是挺简单的 但是看别 ...
- npm in macbook
打开终端,试了很多次 npm install anywhere -g,结果还是报错,大概就说没权限. 所以,才想起之前看过的博客中,提到用sudo去执行. 终于,没问题了! 如果npm install ...
- JavaScript编写代码时候没有提示
如上图所示如果没有提示可能是箭头所指示的类型不正确.