Show engine innodb status 这个命令估计搞MYSQL的听见这个，第一个反应就是烂大街了。这个命令不会你就快回家吧？
OK 那show engine innodb status 展示了多少信息，这些信息对系统的状态的展示你有什么见解？ 什么值能证明什么？ 说到这里，估计快回家的就不少了。
作为一个不想回家的人，我这边的赶紧捋一捋这个 ，烂大街的命令。
1 show engine innodb status 到底展示了多少信息
background thread
semaphores
Latest detected Deadlock
transactions
file i/o
insert buffer and adaptive hash index
log
buffer pool and memory
individual buffer pool info
Row operations
本着学习一个东西，的深入的态度，一般的带着问题来学习
问题 1 当看到下面的信息后，第一个反应应该是什么
这条 show engine innodb stauts 是无用的信息，为什么？ 因为统计一个信息是需要一部分数据来进行计算和统计的，而 last 0 seconds 说明这样的操作数据不是有效的。这样的情况多见于，操作人员不停的执行命令造成的。
下面的信息是从信号量来说的
这里面涉及了数据库与系统交互的一些信息，例如如果看到 os waits 比较大的情况，并且一直在增长的情况，说明 latch 锁征用的情况比较严重.
latch 锁是内存锁，是在一个小型的内存中保护list 的锁的内存结构。
其中他有几个特点 1 不进行排队的操作 2 一个thread 要获得一个latch，则如果这个latch 被占用则空转CPU 来等待这个锁的释放，如果释放后在下一次空转后，如果能获得latch 则进行下一步操作，如果不能则继续自旋。
os waits ，到底目前自旋了多少次。从这个角度可以看到的信息或推测的信息，是否有异常的SQL 造成latch 加重的情况。
下面的transactions 中，是根据当前的数据库的当前值和历史值来判断当前数据库的 purge 状态 以及 undo 等状态是否有异常。另外例如 history list lenght 中显示的UNDO 中未清理的事务数。
同时他也显示的相关事务的连接的信息，如果连接太多，他可能会清除部分的信息，显示部分的最近的信息。
显示文件IO辅助线程的状态——插入缓冲区线程、日志线程、读线程和写线程。它们分别负责插入缓冲区合并、异步日志刷新、预读和脏缓冲区的刷新。
这一片最主要的信息显示读取请求的平均大小。对于随机IO，这些应该是16K页大小，对于全表扫描或索引扫描提前读取，可以执行这些操作，这可以显著增加平均读取大小，通过avg bytes/read fsyncs/s 等你可以了解到目前的系统的状态，以及数据库与系统之间的交互情况。
显示插入缓冲区和自适应哈希状态。第一行显示插入缓冲区的状态——段大小和空闲列表，以及是否有插入缓冲区的记录。接下来，它将显示在插入缓冲区中执行了多少插入、合并了多少recs以及合并了多少次。合并数与插入数之比在很大程度上是插入缓冲区效率。
其实插入缓存（现在应该叫change buffer），的使用率越高，则越正你添加change buffer 的必要性。change buffer 可以有效利用buffer 将一些与I/O可能频繁交互的操作，在buffer 中进行。
上面这一段是比较重要的信息 ,LOG 信息。
其中通过 log sequence number log flushed up to pages fulushed up to last checkpoint at 等四个参数的信息对比就可以了解到目前系统可能存在的瓶颈或可能的问题。
例如如果未刷新的日志的数量已经占整体的数量的 20% - 30% 以上，你就要考虑你的innodb_log_buffer_size 到底是否需要调整。
从这些信息看，可以了解到总的innodb buffer pool 获得的内存有多少，字典信息的buffer 多少， 以及到底目前innodb buffer pool 中使用了多少内存，以及一个重要的师表buffer hit (其他的数据库也有这样的信息，体现到底目前的内存状态）
最后的 row operations 展示了，一些关键的系统信息，例如从系统启动到现在到底插入了多少行 ，更新了多少行，等 并且以每秒的形式来显示，这些都是可以通过信息提取到监控系统中的。
有的时候知识可能需要一遍遍的进行刷新，每一次的刷新都如果都能获得新的启发或建立更多的关联性，那刷新的时间必然是没有浪费的。
