show engine innodb status内容？

这个对你有帮助

很多人让我来阐述一下 SHOW INNODB STATUS 的输出信息, 了解 SHOW INNODB STATUS 都输出了些什么信息，并且我们能从这些信息中获取什么资讯，得以提高 MySQL 性能。
首先，让我们来了解一下 SHOW INNODB STATUS 输出的基础，它打印了很多关于 InnoDB 内部性能相关的计数器、统计、事务处理信息等。在 MySQL 5 中，InnoDB 的性能统计结果也在 SHOW STATUS 结果中显示了。大部分和 SHOW INNODB STATUS 的其他信息相同，在旧版本中还没有这个功能。
SHOW INNODB STATUS 中的很多统计值都是每秒更新一次的，如果你打算利用这些统计值的话，那么最好统计一段时间内的结果。InnoDB 首先输出以下信息：
1.=====================================

2.060717 3:07:56 INNODB MONITOR OUTPUT

3.=====================================

4.Per second averages calculated from the last 44 seconds
首先要确认这是至少统计了 20-30 秒的样本数据。如果平均统计间隔是0或1秒，那么结果就没什么意义了。
说实在的我不喜欢InnoDB提供的平均值，因为很难取得合理的平均间隔统计值，如果你是写脚本来取得 SHOW INNODB STATUS 结果的话，那么最好取得全局的统计结果，然后取得平均值。当然了，直接查看输出的结果信息也是很有用的。
下一部分显示了信号(Semaphores)相关信息：
1.----------

2.SEMAPHORES

3.----------

4.OS WAIT ARRAY INFO: reservation count 13569, signal count 11421

5.--Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:

6.Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0

7.waiters flag 0

8.wait is ending

9.--Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:

10.Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0

11.waiters flag 0

12.wait is ending

13.Mutex spin waits 5672442, rounds 3899888, OS waits 4719

14.RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163
这段可以分成2个部分。一部分是当前的等待，这部分只是包含了在高并发环境下的全部记录，因此 InnoDB 会频繁回退到系统等待。如果等待是通过自旋锁来解决的话，那么这些信息就就不会显示了。
通过这部分信息，你就会知道系统负载的热点在哪了。不过这需要了解一下源码相关的知识 - 从上面的信息中就可以看出来是哪个源码文件中的哪行(不同的版本结果可能不同)，只是从这里却看不出来任何信息。尽管如此，还是可以从文件名中猜到一些东西 - 比如本例中，文件名 "buf0buf.ic" 预示着和一些缓冲池争夺有关系。如果想了解更多，就去看源码吧。
还有一些关于等待的更多细节。"lock var" 表示当前的 mutex 对象的值(被锁住 = 1 / 释放 = 0) 值，"waiters flag" 表示当前的等待个数。另外，本例中还可以看到等待状态信息 "wait is ending"，这表示 mutex 已经释放，但是系统调度线程还正在处理。
第二块是事件统计 - "reservation count" 和 "signal count" 显示了 innodb 使用内部同步阵列的活跃程度 - 时间片(slot)分配以及线程信号使用同步阵列的频繁程度。这些统计信息可以用于表示 innodb 回退到系统等待的频率。还有关于系统等待的直接相关信息，可以看到"OS Waits"的互斥信号灯(mutexes)，以及读写锁。这些信息中显示了互斥锁和共享锁。系统等待和 "保留(reservation)" 不完全一样，在回退到用 sync_array 的复杂等待模式前，innodb 会尝试 "输出(yield)" 到系统，希望下一次调度时间对象里命名线程已经释放了。系统等待相对较慢，如果每秒发生了上万次系统等待，则可能会有问题。另一个观察方法是查看系统状态中的上下文(context)交换频率。
另一块重要的信息是 "spin waits" 和 "spin rounds" 的数量。相较于系统等待，自旋锁是低成本的等待；不过它是一个活跃的等待，会浪费一些cpu资源。因此如果看到大量的自旋等待和自旋轮转，则很显然它浪费了很多cpu资源。浪费cpu时间和无谓的上下文切换之间可以用 innodb_sync_spin_loops 来平衡。
接下来的这段显示死锁状况:
1.------------------------

2.LATEST DETECTED DEADLOCK

3.------------------------

4.060717 4:16:48

5.* (1) TRANSACTION:

6.TRANSACTION 0 42313619, ACTIVE 49 sec, process no 10099, OS thread id 3771312 starting index read

7.mysql tables in use 1, locked 1

8.LOCK WAIT 3 lock struct(s), heap size 320

9.MySQL thread id 30898, query id 100626 localhost root Updating

10.update iz set pad='a' where i=2

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

12.RECORD LOCKS space id 0 page no 16403 n bits 72 index PRIMARY of table test/iz trx id 0 42313619 lock_mode X locks rec but not gap waiting

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

14. 0: len 4; hex 80000002; asc ;; 1: len 6; hex 00000285a78f; asc ;; 2: len 7; hex 00000040150110; asc @ ;; 3: len 10; hex 61202020202020202020; asc a ;;

16.* (2) TRANSACTION:

17.TRANSACTION 0 42313620, ACTIVE 24 sec, process no 10099, OS thread id 4078512 starting index read, thread declared inside InnoDB 500

18.mysql tables in use 1, locked 1

19.3 lock struct(s), heap size 320

20.MySQL thread id 30899, query id 100627 localhost root Updating

21.update iz set pad='a' where i=1

22.* (2) HOLDS THE LOCK(S):

23.RECORD LOCKS space id 0 page no 16403 n bits 72 index PRIMARY of table test/iz trx id 0 42313620 lock_mode X locks rec but not gap

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

25. 0: len 4; hex 80000002; asc ;; 1: len 6; hex 00000285a78f; asc ;; 2: len 7; hex 00000040150110; asc @ ;; 3: len 10; hex 61202020202020202020; asc a ;;

27.* (2) WAITING FOR THIS LOCK TO BE GRANTED:

28.RECORD LOCKS space id 0 page no 16403 n bits 72 index PRIMARY of table test/iz trx id 0 42313620 lock_mode X locks rec but not gap waiting

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

30. 0: len 4; hex 80000001; asc ;; 1: len 6; hex 00000285a78e; asc ;; 2: len 7; hex 000000003411d9; asc 4 ;; 3: len 10; hex 61202020202020202020; asc a ;;

32.* WE ROLL BACK TRANSACTION (2)
这里显示了 Innodb 最后检测到事务引发的死锁，包括发生死锁时的状态，加了什么锁，在等待什么锁释放，以及 Innodb 决定哪个事务会被回滚。注意，innodb只显示了事务持有锁的相关简单信息。并且只显示了每个事务最后执行的语句，发生死锁的记录就是由于这些语句引起的。查看复杂的死锁信息还需要查看日志文件，才能找到真正引发冲突的语句。大部分情况下，SHOW INNODB STATUS 显示的信息基本足够了。
下面是关于外键约束引发的死锁信息：
1.------------------------

2.LATEST FOREIGN KEY ERROR

3.------------------------

4.060717 4:29:00 Transaction:

5.TRANSACTION 0 336342767, ACTIVE 0 sec, process no 3946, OS thread id 1151088992 inserting, thread declared inside InnoDB 500

6.mysql tables in use 1, locked 1

7.3 lock struct(s), heap size 368, undo log entries 1

8.MySQL thread id 9697561, query id 188161264 localhost root update

9.insert into child values(2,2)

10.Foreign key constraint fails for table test/child:

11.,

12. CONSTRAINT child_ibfk_1 FOREIGN KEY (parent_id) REFERENCES parent (id) ON DELETE CASCADE

13.Trying to add in child table, in index par_ind tuple:

14.DATA TUPLE: 2 fields;

15. 0: len 4; hex 80000002; asc ;; 1: len 6; hex 000000000401; asc ;;

17.But in parent table test/parent, in index PRIMARY,

18.the closest match we can find is record:

19.PHYSICAL RECORD: n_fields 3; 1-byte offs TRUE; info bits 0

20. 0: len 4; hex 80000001; asc ;; 1: len 6; hex 0000140c2d8f; asc - ;; 2: len 7; hex 80009c40050084; asc @ ;;
    Innodb会显示引发错误的语句。外键约束定义失败，以及定义关系最密切的父表。有很多嵌接信息都是用16进制表示，不过对于问题诊断并不是太重要，它们主要用于给 Innodb 的开发者来查看或者用于调试目的。
    接下来是显示 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 只会显示他们的数量，减少输出的列表信息，使得输出结果不会太多。